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ABSTRACT 


y 

Over the past twenty years, automated tutoring systems have gained an 
increasing recognition as a prominent area of Artificial Intelligence (AI). During this 
period, Intelligent Computer Aided Instruction (ICAI) systems have been developed 
using a variety of AI techniques to enhance the learning process. The core AI issue 
in designing these systems concerns knowledge representation. A review of 
current AI literature shows that there are numerous, distinctly different knowledge 
representation schemes, and most conventional programming environments do not 
readily support all of these representation schemes. 

This thesis proposes that tutoring systems are best designed in a programming 
environment that supports multiple, integrated knowledge representation schemes. 
Such an environment allows the designer to select and employ, with ease, the most 
natural knowledge representation scheme for each type of knowledge in the tutoring 
system. In this thesis we describe the components of a generalized ICAI system; 
discuss the various types of knowledge and knowledge representation schemes; and 
review the knowledge representation schemes used in several noted ICAI systems. 
In addition, we describe two prototype ICAI systems (Map Reading Tutor and Pilot 
Emergency Procedure Tutor) which we designed and developed in a specific 
programming environment that supports multiple, integrated knowledge 
representation schemes.'^We also analyzed the behavior of both systems and 
discussed how the programming environment has facilitated the construction process 
of the two prototypes and enhanced their overall quality. 
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I. INTRODUCTION 


A. BACKGROUND 

Throughout the 20th century educators have been intrigued with the possibility of 
employing automated tools in the classroom. By the 1950’s a complete industry de¬ 
veloped in this country which provided schools and industry with surprisingly sophis¬ 
ticated mechanical devices, referred to as "teaching machines", to assist educators in 
teaching/training. The advent of the commercially available digital computers in the 
late 1950’s resulted in a new type of automated teaching aid. Computer Aided In¬ 
struction (CAI) systems, which soon became a common application for those early 
computer systems. At the time many educators and computer scientists believed 
that CAI was a panacea for many of the problems that plagued our school systems. 
Consequently, they made exaggerated claims about the short term potential for CAI 
systems to resolve many of these perceived problems. The pioneers of CAI went as 
far as claiming that "through this medium highly individualized (and effective) instruc¬ 
tion would soon be common-place” (Sleeman, 1984, p. 2). Unfortunately, most of the 
early CAI systems failed to live up to the high expectations of their proponents and 
most were considered miserable failures by their users. Probably the best description 
of these early systems is that they were nothing more then sophisticated, electronic 
"page turners" (Barr and Feigenbaum, 1982, p. 225). 

By the late 1960’s it was clear to most observers of the field that a new ap¬ 
proach was needed if the CAI field was to realize its potential. By 1970 many CAI re¬ 
searchers gained better appreciation for the great complexity associated with the 
process of providing effective, individualized instruction. A numbei of these research- 
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ers, particularly those with a background in computer science, concluded that because 
of the extreme complexity and the ill-defined nature of the instructional process that 
artificial intelligence techniques should be employed in the design and development of 
such systems. This conclusion led to research which resulted in an entirely new type 
of tutoring systems, dubbed Intelligent Computer Aided Instruction (ICAI). Jaime 
Carbonell produced the first ICAI system in 1970 when he created his "mixed-initia¬ 
tive" geography tutor, SCHOLAR (Carbonell, 1970). Since CarbonelTs seminal work 
many, widely varying ICAI systems have been developed. 

Most of these intelligent systems took several years to develop but, unfortunate¬ 
ly very few have left the laboratory. Despite this lack of commercial success, much 
has been learned through the development of these ICAI systems. One of the most 
important lessons to come out of this work was the realization that, in order to be ef¬ 
fective, ICAI systems must "capture" and represent knowledge about a number of 
distinctly different domains. Instructional system designers also learned that they 
needed to represent knowledge concerning not only the domain in which they were 
providing instruction, but also knowledge about teaching (pedagogical issues), and 
about the student (cognitive issues) (Pliske and Psotka, 1986, pp. 52-53). In addi¬ 
tion, another type of knowledge, knowledge about communication (interface issues) 
must also be represented in the system. 

Since the knowledge contained in these various domains is very complex and fre¬ 
quently ill-defined, the early ICAI researchers discovered that they needed to repre¬ 
sent distincdy different forms of knowledge within their systems. For example, 
within a typical ICAI system the following forms of knowledge must be represented in 
some manner: declarative knowledge, procedural knowledge, and meta-cognitive 
knowledge (Dede, 1986, p. 333). Because of the diversity of knowledge domains and 
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forms of knowledge, the selection of the knowledge representation method(s) is clear¬ 
ly a significant issue in the design of ICAI systems. 

The development of alternative methods of representing knowledge has always 
been a central issue for AI researchers. Because of this great emphasis, in the past 
35 years AI researchers have developed many different knowledge representation 
methodologies to support their computational requirements. These methodologies or 
schemes include: formal logic-based representations, procedural representations, as¬ 
sociative representations, production systems, structured object representations, and 
other special purpose representation schemes (Barr & Feigenbaum, 1982, pp. xiii - 
xix). Each representation scheme has its strengths and weaknesses, and is usually 
well suited for representing only a subset of the knowledge types. Consequently, 
since an effective ICAI system must capture various types of knowledge from a num¬ 
ber of different domains, the programming language/environment in which these sys¬ 
tems are designed should support multiple knowledge representation schemes. In 
addition these multiple schemes should be fully integrated to allow the designer to 
work with many different forms of knowledge simultaneously. Unfortunately, while it 
is theoretically feasible to implement all of the knowledge schemes mentioned above 
in any programming language/environment, there are actually only a few programming 
environments which readily support multiple, integrated, knowledge representation 
schemes. Most AI researchers believe that the selection of the most natural repre¬ 
sentation schemes for the knowledge in a given application is one of the most impor¬ 
tant design decision made by an AI system developer. Consequently, the process of 
designing and developing an effective ICAI system is unnecessarily impeded if it is 
done in a programming environment which does not support multiple, integrated 
knowledge representation schemes. 
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B. OBJECTIVE 

The purpose and intent of this thesis is to demonstrate that the most suitable pro¬ 
gramming environment for designing and developing an Intelligent Computer Aided In¬ 
struction system is one which supports multiple, integrated knowledge representation 
schemes. In order to support this claim we have designed and implemented two sep¬ 
arate ICAI system prototypes in such an environment. 

C. ORGANIZATION 

Chapters II and III of this thesis provide overviews of generalized ICAI systems 
and knowledge representation schemes, respectively. Chapter IV discusses knowl¬ 
edge representation issues as they relate to specific ICAI systems. The following 
chapter presents an overview of the development environment we used to design and 
construct two ICAI applications. Chapters VI and VII describe the ICAI systems 
that we developed in detail. Finally, Chapter Vni discusses how the availability of 
multiple integrated knowledge representation schemes enhanced the development of 
both applications. The appendices contain sample tutoring sessions of the two appli¬ 
cations and a description of where interested readers may gain access to the source 
code. 
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n. INTELLIGENT COMPUTER AIDED INSTRUCTION SYSTEMS 


A. INTRODUCTION 

The history of Computer Aided Instruction began in the early I960’s and during 
the past thirty years the technology has matured and the demand for such systems 
has increased greatly. In response to this demand, a number of powerful CAT author¬ 
ing tools/environments were developed. The most notable of these tools include 
PLATO, TICCIT, and WICAT (Kearsley, 1987, p. 29). Employment of these and oth¬ 
er authoring tools resulted in a significant reduction in the overall difficultly of design¬ 
ing and implementing CAI systems. Because of this reduction in difficulty and 
continued demand, over ten thousand CAI systems, generally referred to as 
"courseware" have been developed (Anderson et al, 1985, p. 456). To the credit of 
the designers of these systems, some systems provide adequate instruction in very 
restricted domains. Unfortunately, the overwhelming majority of these systems suf¬ 
fer from severe limitations. 

B. FROMCAITOICAI 

The primary motivation for the researchers who developed the first ICAI systems 
were the numerous shortcomings which were evident in existing CAI systems. 
These shortcomings have been described by many researchers working in the ICAI 
field (Sleeman, 1984; Pliske, 1986; Carbonell, 1970). Marlene Jones provided an es¬ 
pecially detailed enumeration of these limitations (Jones, 1984, p. 517). She claims 
that most CAI systems suffer form the following limitations: 

(i) an inability to conduct conversations with the student in the students natural 
language; 




(ii) an inability to understand the subject matter being taught, thus being able to 
anticipate responses (or answer student questions); 

(iii) an inability to decide (reason about) what should be taught next; 

(iv) an inability to anticipate, diagnose, and understand the student’s mistakes 
and misconceptions; 

(v) an inability to improve or modify current teaching strategies or learn new 
ones. 

These shortcomings and others were clearly obvious to nearly everyone who 
worked in the field of computer aided instruction. Unfortunately, the majority of re¬ 
searchers working in the CAI field were not aware of, or did not know how to employ, 
the "tools" that are necessary to address/mitigate these shortcomings. 

On the other hand, AI researchers, particularly those working in the areas of natu¬ 
ral language understanding, expert systems, machine learning, and knowledge repre¬ 
sentation, were able to recognize the clear correspondence between their research 
interests and the limitations of conventional CAI systems. A number of these re¬ 
searchers applied various AI techniques to the development of CAI systems in at¬ 
tempts to alleviate some of the acknowledged shortcomings. The goal of these 
researchers was to improve the quality and effectiveness of computer aided instruc¬ 
tion systems by designing systems which more closely simulated the instructional 
process that takes place between a human tutor and student (i.e., systems which act¬ 
ed in a more intelligent manner). The result of their combined efforts was a new class 
of instructional sytem; appropriately named Intelligent Computer Aided Instructional 
systems. 

C. COMPARISON BETWEEN CAI SYSTEMS AND ICAI SYSTEMS 

Although ICAI systems were first developed to improve upon and extend the ca¬ 
pabilities of "conventional" CAI systems, there are a number of fundamental differenc¬ 
es between these two types of instructional systems. A description of the differences 
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between the two system types is presented here to provide the reader with a better 
overall understanding of ICAI systems. Greg Kearsley provides an excellent descrip¬ 
tion of these differences (Kearsley, 1987, pp. 3-10). He argues that typical ICAI and 
CAI systems differ in the following areas: development goals, theoretical bases of the 
designers, instructional principles, methods of structuring knowledge 
(representation), methods of student modeling, subject matter areas, system devel¬ 
opment process, and finally, hardware and software differences. Most of these differ¬ 
ences can be attributed to the contrasting backgrounds of the respective developers of 
these two types of systems. Conventional CAI systems are normally designed by 
educational and psychology researchers. ICAI systems, on the other hand are usual¬ 
ly developed exclusively by AI researchers. The designers of ICAI systems are typi¬ 
cally most interested in do empirical testing to determining the desirability of applying 
a particular AI technique to enhance the learning process. Conversely, CAI develop¬ 
ers are primarily interested in developing marketable, commercial tutoring systems. 
In other words, ICAI developers are mostly concerned with the "means" while CAI 
developers are primarily concerned with the "ends." (Kearsley, 1987, p. 3-10) 

It should be noted that in recent years CAI developers have begun to incorporate 
many of the lessons learned in the development of ICAI system. Consequently, the 
line which divides the two types of systems is becoming somewhat blurred (Wegner, 
1987, p. 5). In the absence of any other indicators, a determination of whether or not 
an instructional system is an ICAI can be based on two important factors. First, if the 
system is both a dynamically adaptive learning environment, and second, if the sys¬ 
tem appears to "know" (i.e., can reason about) the knowledge it is attempting to 
teach, then it can be considered an ICAI. If, on the other hand, the system appears to 
be presenting a pre-programed sequence of text and graphics and can not dynamically 
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adapt to meet the instructional needs of individual students then the system can not 
be considered an ICAI. 

Many authors use a more strict definition of ICAI systems which includes the re¬ 
quirement that the systems adhere to a particular architecture (i.e., that it must have 
a particular set of components) before it can be considered an ICAI. We don’t believe 
that such a restriction should be placed on the definition; however, the architectures 
that these authors propose provides an excellent framework for describing the compo¬ 
nents found in most existing ICAI systems. 

D. COMPONENTS OF ICAI SYSTEMS 

Providing adaptive and individualized instruction is an extremely complex process 
which involves two agents; a student and a tutor, a body of knowledge, and a commu¬ 
nication medium. Because of this obvious complexity, the first group of AI research¬ 
ers who worked in the field concluded that it should be broken down into logical 
modules. As early as 1973 Hartley and Sleeman concluded that a generalized ICAI 
should have at least four distinct components: (1) knowledge of the domain, (2) a 
model of the student, (3) a set of teaching operations, and (4) a set of teaching guid¬ 
ance rules (Park, 1987, p. 274). In recent years many other authors have proposed a 
variety of models to describe generalized ICAI systems (Seidel, 1988; Woolf, 1987; 
Tennyson, 1987; Nawrocki, 1987). These various models appear to have seemingly 
very different component schemes, however, most of the models differ only in a cos¬ 
metic manner. 

The most widely accepted model of a generalized ICAI consists of the following 
modules/components; the domain knowledge model, the student model, the tutoi mod¬ 
el, and the communication model (Woolf, 1987, pp. 1-44). Note that the only differ¬ 
ence between this model and the original model proposed by Hartley is that the third 
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and fourth components of Hartley’s model have been combined into one component 
and a new component, the communicadons model, has been added. Figure 1 shows 
the model and the interaction among the various components. It should be noted that 
in most ICAI systems one or more of these modules are either not fully developed or 
nonexistent. The reason for this "shortcoming" is that most ICAI researchers imple¬ 
mented their systems in order to validate a specific hypotheses and consequently 
they usually focused on one particular module, at the expense of the others 
(Duchastel, 1986, p.l03). 



Figure 1 • Model of a Generalized ICAI System 
1. Domain Knowledge Model 

The domain knowledge model is the component of the system in which the sub¬ 
ject matter expertise is represented. All tutoring systems, including both CAI and 
ICAI systems, have some form of knowledge model. The knowledge model of a typi- 
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cal ICAI is significantly more sophisticated than the corresponding module in a CAL 
In most CAI systems, for example, the knowledge model is merely a description of 
concepts and skills that a student should acquire. This coarsely grained and ex¬ 
tremely restricted form of knowledge representation prevents CAI systems from rea¬ 
soning with/about the domain knowledge. The knowledge models of most ICAI 
systems, on the other hand, explicitly supports reasoning and inferences about the do¬ 
main knowledge by the system. In addition, many ICAI systems represent the do¬ 
main knowledge as a sophisticated, executable model thereby making a "dynamic" 
form of the knowledge available to the system (Wegner, 1987, p. 14). 

In an ICAI system, the domain knowledge model serves three distinct purpos¬ 
es. First, the domain knowledge model is the source of the knowledge which is being 
imparted to the student. Second, the domain knowledge model provides a solution to 
the problem that the system has posed to the student. Third, the domain knowledge 
model reasons about and prepares responses to questions posed by the student 
(note: this requirement does not imply that all ICAI must have a natural language in¬ 
terface. In some reactive environments the student poses a "question" by taking 
some action which alters the state of the system). AI researchers have employed a 
number of AI techniques to provide this functionality to their domain knowledge mod¬ 
els. (Wegner, 1987, pp. 14-15) 

2. Student Model 

The student model is the component of the system in which evidence concern¬ 
ing the knowledge that the student has acquired is gathered and represented. The 
student model can be cither, a simple declarative record of the student’s knowledge, 
or a sophisticated diagnostic model which evaluates the student’s responses and in¬ 
fers the current state of the student’s knowledge. In addition, the representation of a 
student’s knowledge can be either quantitatively based or based on some form of 
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qualitative representation. In many ICAI systems, the student model represents the 
student’s knowledge only as a subset of the expert’s knowledge. In these systems 
the student model is referred to as an "overlay model." In other systems, the student 
model also represent student misconceptions about the knowledge domain. These 
models are called "buggy" models. (Kearsley, 1988, p. 17) 

An extremely important consideration in the student model is the assignment 
of "credit" for correct responses and "blame" for incorrect responses. Since it is very 
difficult for human tutors to make this type of determination, this is an especially diffi¬ 
cult problem for an automated system. Another issue which adversely affects the de¬ 
velopment of suitable student models is the fact that students do not always make 
mistakes because of a lack of knowledge. They also make mistakes for a variety of 
other reasons including carelessness and fatigue. Consequently many ICAI systems 
employ sophisticated techniques to handle this type of "noisy" data. (Sleeman and 
Brown, 1982, p. 4) 

3. Tutor Model 

The tutor model is the component of the system in which the pedagogical 
knowledge of the system is represented. The tutoring strategy that an ICAI system 
employs is typically encapsulated in the tutor model. The tutor model performs two 
distinct functions: (1) determination of the student’s instructional needs, and (2) se¬ 
lection and presentation of domain knowledge to the student (Park, 1988, p. 9). In 
ICAI systems the tutoring model performs these functions by reasoning about the 
student’s learning needs and about what to present to the student next. In most sys¬ 
tems this reasoning is accomplished by interacting with the student model and 
through the execution of an explicit procedure or through the application of production 
rules. 
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Over the years ICAI developers have implemented a wide variety of tutoring 
strategies/approaches. Most of these approaches fall into two general categories: the 
Socratic method, and the coaching method (Kearsley, 1987, p. 17). In the Socratic 
method, the student is provided with questions which "guide" him through resolution 
of his misconceptions. In the coaching method, the student is provided with a reactive 
learning environment in which the coach interrupts only when necessary to insure that 
the student is learning new concepts as a "side-effect" of the students actions. An¬ 
other common tutoring strategy, which does not fit into the two categories listed 
above, is the "discovery" learning method. In this method there is no explicit tutor 
model. Instead the student has full initiative and is not interrupted by the system at 
any time. 

4. Communications Model 

The communications model is the component of the system in which knowl¬ 
edge about the interface to the student is represented. The communications model 
serves two important functions: (1) interpretation of the students responses, and (2) 
display of the system’s output to the screen (Park, 1987, p. 237). Many early ICAI 
researchers down played the importance of this module. In fact most of the early 
ICAI component models did not include an explicit communication model. The commu¬ 
nication model has achieved greater relative importance over the years, due to the de¬ 
velopment of sophisticated and expressive graphical interfaces and improved natural 
language understanding systems. 

In some systems natural language understanding and generation systems are 
employed. These systems control the discourse between the student and the sys¬ 
tem. Other systems have no natural language understanding system. These sys¬ 
tems, instead, depend upon a sophisticated graphical interface to communicate with 
the student. Many current system employ a combination of these two techniques. 
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E. SUMMARY 

There are some significant differences between conventional CAI rind ICAI sys¬ 
tems. In recent years, however, the line which divides the two types of systems is 
becoming blurred as more CAI system designers "borrow" AI techniques in the de¬ 
sign and implementation of their systems. 

The four component model of a generalized ICAI is widely accepted by contempo¬ 
rary ICAI researchers. Although there is considerable divergence of opinion about 
the particular functions that each module should perform, there is little dispute about 
the overall framework of the model. An understanding of the model and its four com¬ 
ponents provides a framework for discui>sing the knowledge representation issues 
which must be addressed in the design and implementation of an ICAI system. 
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in. KNOWLEDGE REPRESENTATION METHODOLOGIES 


A. INTRODUCTION 

Knowledge can be considered a collection of related facts, procedures, models and 
heuristics that can be used in problem solving or inference systems (Tanimoto, 
1987 p. 80). 

Knowledge and knowledge representation have always been fundamental issues 
in AI research. Many AI researchers, in fact, believe that knowledge representation 
is the single most important issue in AI (Barr & Feigenbaum, 1982, p. 159). One of 
the primary reasons for this belief is the fact that knowledge representation is a cen¬ 
tral concern in every sub-field of AI. During the early years of AI research, research¬ 
ers realized that if they wished to design systems which exhibited intelligent 
behavior they needed to develop knowledge representation schemes which allowed 
their systems to "reason" about, and make inferences from, the knowledge that the 
system uses. 

It should be noted that AI researchers did not "invent" the knowledge representa¬ 
tion issue, and the knowledge representation issue not a new concern. In fact, man¬ 
kind has been wrestling with this issue since the time of Aristotle (Brachman & 
Levesque, 1985, p. xiv). Further, the theories upon which many knowledge represen¬ 
tation schemes are based were developed many years prior to the invention of digital 
computers. For example, the logic theories of Boole, Frege, and Russel, which were 
devised in the eighteenth century, are the theoretical foundations of all logic represen¬ 
tation schemes (Barr & Feigenbaum, 1982, p. 160). 
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B. TYPES OF KNOWLEDGE 

It is widely accepted that knowledge can take on many different forms and that 
these different forms can be categorized in a number of different ways. Unfortunately 
there is little agreement among AI researchers as to the manner in which knowledge 
can be categorized. For example, four different forms of knowledge are described in 
the Handbook of Arrificial Intelligence (Barr and Feigenbaum, 1982, p. 146): knowl¬ 
edge about objects, knowledge about events, knowledge about performance and 
knowledge about knowledge. On the other hand, Beverley Woolf, an authority in the 
ICAI field, believes there are three types of knowledge: conceptual knowledge, proce¬ 
dural knowledge and heuristic knowledge (Woolf, 1986, p. 47). A number of other au¬ 
thors have proposed different category breakdowns for knowledge (Gevarter, 1978; 
Dede, 1986). 

We will use a classification system for the types of knowledge which is based up¬ 
on the categorizations mentioned above. In this classification system, all knowledge 
is divided into the following general categories: declarative knowledge, procedural 
knowledge and meta-knowledge. Later we will use this categorization as the basis 
for our discussion of knowledge representation schemes. 

Declarative knowledge is factual information about physical objects and abstract 
concepts. Specifically, it defines the static state of objects or concepts. In simple 
terms, declarative knowledge can be used to answer the "what" question. The name 
height and weight of a person are examples of declarative knowledge. 

Procedural knowledge is the information concerning actions and events in the 
physical world. The actions that procedural knowledge describes can be considered 
to be operations which cause changes or transitions to the static state of objects. In 
other words, procedural knowledge is used primarily to answers the "how" question. 
An example of procedural knowledge is a description of the process of driving a car. 
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Meta knowledge is knowledge about, or concerning, knowledge. For the purpos¬ 
es of definition the following types of knowledge (and others) can be classified as me¬ 
ta-knowledge: heuristics, certainties, and constraints. Heuristics, for example, can 
be considered to be knowledge about when to apply certain procedures. Certainties 
and constraints, on the other hand, can be considered to be knowledge about declara¬ 
tive facts. 

C. KNOWLEDGE REPRESENTATION METHODOLOGIES 

Through the years, AI researchers have developed a number of distinctly different 
knowledge representation schemes. In this section, we present five of the more 
prominent and historically significant categories of representation schemes. They are: 
formal logic-based representations, associative representations, procedural represen¬ 
tations, production systems, and structured object representations. Most of the rep¬ 
resentation schemes that have been proposed by AI researchers during the past 
thirty years fall into these five general categories (Brachman and Levesque, 1985). 

It should be noted that many of the proponents of each category of representation 
schemes believe that their scheme should be used exclusively for representing all 
knowledge. The well known and hard fought "proceduralist vs. declarativist" debate 
was based upon such extreme beliefs (Winograd, 1975, p. 358). In this thesis, how¬ 
ever, we take the less extreme position that some types of knowledge are best repre¬ 
sented by a particular representation scheme, while other types of knowledge might 
be better represented by another representation scheme. It is also our belief that 
some knowledge can be best represented by multiple representation schemes. In ad¬ 
dition, we believe that the manner in which the knowledge is used by the system 
plays a large role in determining the most suitable representation scheme for a specif¬ 
ic body of knowledge. 
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A survey of the five general categories of representation methodologies follows 
this section. A general description of each methodology and the strengths and weak¬ 
nesses of each will be presented. The different representation schemes will be de¬ 
scribed and compared against each other using the following set of characteristics of 
representation schemes: modularity, understandability, completeness, consistency, 
grain size, and flexibility. (Winograd, 1975, p. 359; Barr & Feigenbaum, 1982, p. 147) 

1. Formal Logic-based Representations 

Formal logic has long been used to represent knowledge. One of the founding 
fathers of AI, John McCarthy, was an early proponent for the development of a logical 
formalism for representing knowledge. Using propositional logic, the simplest form of 
logic, all knowledge is represented as a set of declarative facts. These declarative 
facts are referred as axioms and are normally in the form of statements or logical sen¬ 
tences which adhere to a strict syntax. An inference mechanism is applied to these 
axioms to determine if other statements can be proved or inferred. This inference 
mechanism is based on the formal rules of logic. In predicate logic-based representa¬ 
tion schemes, the expressiveness of the formalism is extended to include both predi¬ 
cates and the additional inference mechanism necessary to operate on these more 
complex statements. First-order logic systems have been extended further to include 
the concepts of functions and equality of predicates (Barr & Feigenbaum, 1982, pp. 
160-171; McCarthy, 1977, p. 24). 

There are many advantages using logical representation for knowledge. First, 
it is complete and sound, i.e., all true statements can be proved and all proved state¬ 
ments are true. Another important advantage of this scheme is the modularity and 
fine granularity of the knowledge that can be represented using formal logic. This mod¬ 
ularity and fine granularity results from the fact that each new statement that is added 
into the system is completely independent of any other axiom. Still another advan- 
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tagc of logic-based representation schemes is the flexibility that this scheme pro¬ 
vides in the manner in which facts are used. (Barr & Feigenbaum, 1982, p. 160-171) 

Despite these advantages, formal logic-based systems suffer from a number of 
serious disadvantages. First, the introduction of a large number of logical sentences 
into such a system often results in a "combinatorial explosion", due to lack of struc¬ 
ture in a logic representation. Efforts to restrict the reasoning process has only miti¬ 
gated, but not solved this problem. Another serious disadvantage of this scheme is 
that it is very difficult to group related facts or represent procedural knowledge. 

There is yet another serious disadvantage associated with it the use of logic 
as the basis for a knowledge representation scheme. Although the reference mecha¬ 
nism is truth preserving, the semantic relationships between objects may be lost in 
the representation, resulting in logically valid, but semantically meaningless conclu¬ 
sions. 

2. Associational Representations 

M. Ross Quillian is credited with originating the concept of the semantic net¬ 
work upon which nearly all associational representation schemes are based. In Quil- 
lian’s seminal dissertation he developed a representation scheme which was based 
upon his theoretical model of human long-term memory. According to his theory, the 
human memory consists of "a mass of nodes, interconnected by different kinds of as¬ 
sociative links" (Quillian, 1967, p. 99). The nodes in his model usually represent con¬ 
cepts and the links represent specific relationships between two nodes in the model 
(Barr & Feigenbaum, 1982, p. 181). 

Quillian developed his memory model, now commonly referred to as a semantic 
net, as the representation scheme for the knowledge in a natural language under¬ 
standing system. Since he published his woric in the late 1960’s AI researchers have 
used semantic nets in a wide variety of applications. These applications include: com- 
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puter based psychological models, natural language understanding systems, data 
base management systems, and intelligent tutoring systems. Many of the research¬ 
ers who used Quillian’s theory have extended and modified the concept and, conse¬ 
quently, there are now numerous types of semantic networks. (Bair & Feigenbaum, 
1982, p. 180) 

Associative representation schemes offer a number of advantages. The princi¬ 
ple advantage of this scheme is that it is easy to represent both the descriptive facts 
about a particular object or concept and its relationships with other objects or con¬ 
cepts. In addition, since a significant amount of human knowledge concerns the rela¬ 
tionships that exist between objects or concepts this scheme readily supports the 
representation of this type of knowledge. Yet another advantage of this scheme is 
that the knowledge represented in a semantic net is usually in a readily understand¬ 
able form. (Quillian, 1967, pp. 98-117) 

Unfortunately, some problems result from the use of associational representa¬ 
tion schemes. Since there are no formal inference rules, as there are in logic-based 
schemes, the conclusions inferred from the network are not guaranteed to be complete 
or consistent. In addition, it is very difficult to represent procedural knowledge in a 
semantic net. Further, associational representation schemes normally suffer from 
combinatorial problems as size and complexity of the system grows. (Barr & Feigen¬ 
baum, 1982, pp. 180-189) 

3. Procedural Representations 

Advocates of procedural representation schemes were motivated in their re¬ 
search by the inherent disadvantages associated with declarative-based representa¬ 
tion schemes. Despite the claims of "declarativists", much of the knowledge that 
humans possess, and which AI researchers wish to represent in their systems, is 
procedural in nature. Terry Winograd made this point effectively when he stated "It is 
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an obvious fact that many things we know are best seen as procedures, and it is diffi¬ 
cult to describe them in a purely declarative way" (Winograd, 1975, p. 187). Another 
important issue is the fact that all computer applications, including ICAl’s, have at 
least some part of their knowledge represented in a procedural form. 

The principle advantage to procedural representation schemes is very obvious; 
such schemes explicitly support the representation of procedural knowledge. In addi¬ 
tion, because procedures are "direct in their problem solving activity", the combinato¬ 
rial problems associated with logic-based and associational representations schemes 
are avoided. In addition, because of this "direct" nature procedural representation 
schemes are also ideal for representing heuristic knowledge in an efficient and explicit 
manner. (Barr & Feigenbaum, 1982, pp. 173-179) 

The principle disadvantage of using procedural representation schemes is that 
as the system evolves it becomes increasingly difficult to modify and extend the sys¬ 
tem. Another important disadvantage of procedural representation schemes is that in 
most cases it is more difficult for humans to understand the knowledge that is repre¬ 
sented in such a scheme than knowledge that is represented a declarative manner. 
Furthermore, since procedural representation schemes are not based on formal logic 
they do not provided completeness or consistency. Finally, because control informa¬ 
tion and knowledge are so closely tied in procedural representation schemes, these 
schemes sacrifice much of the flexibility that is achieved in declarative representation 
schemes. (Barr & Feigenbaum, 1982, pp. 173-179) 

4. Production System 

A production system is made up of a collection of IF-THEN rules (referred to 
as production rules or, more simply, as productions) and a simple inference mecha¬ 
nism. In a Q^ical production system each production rule is a simple conditional 
statement that contains a set of premises and a conclusion. Each rule is an indepen- 
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dent, modular section of code which represents a specific aspect of the knowledge do¬ 
main. 

The principle advantage of employing production rules as a representation 
scheme is the modularity of the rules. Production systems can be easily modified and 
extended because existing rules can be changed and new rules can be added to the 
system at any time and without altering other rules. The use of production rules also 
greatly simplifies the process of acquiring knowledge from domain experts who are 
not familiar with AI techniques. The reason for this simplification is that the if-then 
syntax of production rule is similar to the way that many human experts structure 
(i.e., think about) their knowledge. Yet another advantage offered by a production 
rule facility is that it is relatively easy to implement an explanation facility in such a 
system. (Davis & Buchman, 1977) 

The principle disadvantages of production systems is that it is awkward to rep¬ 
resent non-procedural knowledge in such a system (Tanimoto, 1987, p. 130). A ma¬ 
jor problem with production systems is that the reasoning process is completely 
mechanical and these system only reason about the knowledge that has been explicit¬ 
ly defined. In addition, it is difficult to represent explicitly sequential algorithms in 
production rules. (Barr & Feigenbaum, 1982, pp. 189-199) 

5. Structured Object Representations 

Representing knowledge in the form of structured objects was first pioneered 
by Marvin Minsky. In his seminal article " A Framework for Representing Knowl¬ 
edge" he introduced the concept of "frames". The motivation for his work was a de¬ 
sire to develop a representation methodology that closely modeled the cognitive 
process. Minsky felt that the existing methods of knowledge representation were loo 
finely grained and he proposed that knowledge is more than just a "collection of sepa¬ 
rate, simple fragments". In the appendix of the article he claims that knowledge rep- 
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resentations based upon logical formalisms "do not work" in realistic, complex 
domains. (Minsky, 1981, pp. 95-128) 

According to Minsky "A frame is a data-stnicture for representing a stereo¬ 
typed situation ... (and) attached to each frame are several kinds of information" 
(Minsky, 1981, p. 95). In the system that he proposed the individual frames are 
linked together into a framework based upon the relationships between the frames. 
The "stereotypical situations" that Minsky describes can be either concepts, physical 
objects, or events. The "several kinds of information" he alludes to can be considered 
description or attributes of the stereotypical situation. An important feature of Min¬ 
sky’s frame system is that both procedural knowledge and declarative knowledge can 
be attached to frames. 

Many researchers have extended and revised Minsky’s original concept. Cur¬ 
rently most of the ideas that Minsky put forth are subsumed into the active area of re¬ 
search referred to as object oriented programming. The most significant concept that 
has been added to Minsky’s theory is the distinction between classes and instances 
(Malpas, 1987, p. 273). In addition, most object-oriented systems explicitly support 
the construction of inheritance hierarchies (frameworks) based only on the "IS-A" re¬ 
lation. The development of frameworks based upon other relations, such as the 
"PART-OF" relation, is normally not explicitly supported. 

The primary advantage that structured object representation schemes provides 
is that both procedural and declarative knowledge can be easily represented in a logi¬ 
cal structure. This logical structure simplifies the acquisition, storage, and modifica¬ 
tion of the knowledge. In addition, this scheme supports the notion of "default 
reasoning" and consequently the construction of an inference mechanism can be great¬ 
ly simplifred. 
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The principle disadvantage of this representation scheme is that use of default 
reasoning can result in incorrect conclusions. In addition, the use of multiple inherit¬ 
ance, which most present day frame-based systems support, can also cause incorrect 
conclusions to be inferred. 

D. SUMMARY 

The representation of knowledge has been, and continues to be, at the core of AI 
research. Over the years a number of very different representation schemes have 
been proposed and implemented in AI systems. Each of these representation meth¬ 
odologies emphasize a particular aspect the of knowledge representation issue and 
each offers both advantages and disadvantages. In addition, each representation 
scheme is especially well suited at representing some forms of knowledge and less 
effective at representing other forms. Most complex AI systems, like ICAI systems 
for instance, are made up of a wide variety of knowledge types and forms. Conse¬ 
quently, a single knowledge representation scheme is generally not suitable for such 
systems. Instead a programming environment that supports multiple, integrated rep¬ 
resentation schemes should be used in the design and development of such systems. 







IV. KNOWLEDGE REPRESENTATION ISSUES IN ICAI SYSTEMS 

A. INTRODUCTION 

We have established the importance of knowledge representation in AI in general 
and in ICAI systems in particular. We have also established that over the years AI 
researchers have developed a number of distinctly different knowledge representation 
schemes. Not surprisingly, the designers of existing ICAI systems have used many 
different schemes to represent knowledge in their systems. The following review will 
provide a brief description of five historically significant ICAI systems. The develop¬ 
ers of each of these systems took a different approach to the issue of knowledge rep¬ 
resentation. 

B. KNOWLEDGE REPRESENTATION IN EXISTING ICAI SYSTEMS 
1. SCHOLAR 

As mentioned earlier, SCHOLAR was the first Computer Aided Instruction 
system developed using AI techniques. It was designed and implemented by Jaime 
Carbonell and it provides instruction in the domain of South American geography. Its 
most notable feature is that it provides a "mixed-initiative" environment in which the 
student plays an active, rather than a passive, role in the instructional process. A de¬ 
scription of the system was first published by Carbonell as pan of his Doctoral disser¬ 
tation in 1969. He later extended and modified, the system in conjunction with his 
associates when he was employed at Bolt, Beranek, and Newman, Inc. (BBN). (Barr 
& Feigenbaum, 1982, pp. 236-241) 
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When Carbonell began work on SCHOLAR his intention was to implement a 
sophisticated instructional system with the functionality that is provided by all four 
components of the generalized ICAI model. In order to provide this functionality, he 
needed to represent a significant amount of knowledge in various forms. He elected 
to use a semantic network as the principle representation scheme in his system. The 
semantic network which he constructed serves as the basis for the representation of 
nearly all of the knowledge in the system. 

The domain knowledge in SCHOLAR is primarily a set of declarative facts. 
As a result, Carbonell was able to construct a detailed semantic network which effec¬ 
tively represented the domain knowledge (see figure 2), The nodes in the network 
represent physical objects (for instance, Argentina) or concepts (for example, lati¬ 
tude) and the arcs in the network represent the relationships between the nodes (for 
example, super class). By employing a semantic network Carbonell achieved a high 
degree of flexibility that allowed him to use the knowledge in a variety of ways. Be¬ 
cause of this flexibility he was able to use the network as the basis for the other com¬ 
ponents in the system. (Carbonell, 1970, pp. 190-202) 

Carbonell also used the semantic network as the basis for his model of the stu¬ 
dent. In the system the student is initially modeled in terms of the full semantic net¬ 
work (i.e., the student is assumed to "know" everything about the domain before 
instruction begins). As a typical student uses the system, however, he normally 
demonstrates that he possesses one or more misconceptions related to the subject 
matter. The system diagnoses these misconceptions and uses this information to up¬ 
date the student model. It updates the student model by modifying the nodes and/or 
links in the semantic net which represents the student’s knowledge of the subject 
matter. (Wegner, 1987, p. 37) 
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Figure 2 - Example Semantic Network from SCHOLAR (Wagner, 1987, p. 32) 

The tutoring model in SCHOLAR also makes extensive use of the semantic 
net to perform their functions. The tutoring model in SCHOLAR encapsulates a 
Socratic dialogue tutoring strategy. A Socratic dialogue is an interaction between a 
tutor and a student in which the tutor assists the student in the resolution of his mis¬ 
conceptions by asking well-timed and pointed questions (Kearsley, 1987, p. 17). The 
tutoring model, in SCHOLAR, provides Socratic tutoring by responding to the miscon¬ 
ceptions that are reflected in the semantic network which models the student. 


















scholar’s communicarion model also uses the semantic network extensive¬ 
ly to perform its function. The communication model takes advantage of the manner in 
which facts are structures in the semantic network. It uses the structure of the net- 
woik: to formulate both natural language questions for the student and natural lan¬ 
guage responses to the student’s questions. The communication model interprets the 
student’s questions by looking for semantic clues in his input. It uses these clues to 
determine the meaning of the student’s question and extract information from the se¬ 
mantic network. 

2. BUGGY 

BUGGY is a diagnostic system which diagnoses student misconceptions 
about the procedures involved in doing subtraction. The system was designed in the 
late 1970’s by two leading authorities in the ICAI field, John Seely Brown and Richard 
Burton. DEBUGGY was originally on off-line system, however, it was later upgrad¬ 
ed into an on-line, interactive system called IDEBUGGY. Although, all four compo¬ 
nents of a generalized ICAI are present in IDEBUGGY; the knowledge model and the 
student model are the most interesting. These two models are especially interesting 
for two reasons. First, because of the theory upon which these models were based, 
and second, because of the unique representation scheme that was used to capture 
the knowledge in both models. (Barr & Feigenbaum, 1982, p. 279) 

The theory that the designers of this sytem used was that students make er¬ 
rors in the performance of procedural skills not as a result of an inability to follow pro¬ 
cedures, but instead, because they have learned one or more faulty sub-procedures. 
The designers developed a cognitive model based on this theory which they called the 
'Buggy model." Their buggy model served as the basis for both the knowledge model 
and the student model, in DEBUGGY and its descendants (Burton, 1982, pp. 157- 
187). 
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The designers of DEBL'GGY used a procedural network as the knowledge rep¬ 
resentation scheme to implement their theoretical model. Consequently, their domain 
knowledge model consists of a detailed procedure which performs the subtraction op¬ 
eration. They broke this "expert" procedure into a lattice of finely grained sub-proce¬ 
dures in which each sub-procedure encapsulates a specific subskill of subtraction. 
Burton defines a subskill as "any isolatable part of the skill that it is possible to mis- 
leam" (Burton, 1982, p. 177). 

In the system, the student model was not a conventional "overly" model (in 
which the student is assumed to possess a subset of the expert’s knowledge). In¬ 
stead, the model of the student’s knowledge state was based on the semantic net¬ 
work. The use of a procedural network allows for the student’s knowledge of the 
subject matter to be easily modeled. The reason for this ease of modeling is that for 
procedural skills, a student can always be assumed to possess a variation or pertur¬ 
bation of the procedural network which represents the expen's knowledge. (Bunon, 
1982, pp. 157-187) 

The original system worked in the following manner. The student takes a test 
(off-line) which consisted of 12 multi-column subtraction problems. His answers are 
provided to the system and if errors are detected the system attempts to infer the 
cause of the errors (i.e., diagnose the student’s "bugs"). The system makes this in¬ 
ference by replacing one or more of the sub-procedures in the procedural network with 
"buggy" procedures. The system would continue making substitutions until the sys¬ 
tem could either generate results that were "close" to the answers provide by the stu¬ 
dent. The specific modified procedural network that produces the set of answers 
which were the "closest match" is an accurate model of the student’s knowledge of 
the subtraction operation. Each of the "buggy" procedures in this student model rep¬ 
resents specific misconceptions that the students has demonstrated in his work. 
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3. GUIDON 

The subject matter addressed in GUIDON is infectious blood disorders. The 
system was designed and developed by Clancey and others at the University of Stan¬ 
ford in the late 70’s and early eighties. The system went through numerous revi¬ 
sions and extensions until work was discontinued on the project in 1985. The most 
notable characteristic of GUIDON is that it was the first mtoring system which was 
based upon an existing expen system. (Clancey, 1986, p. 40) 

The domain knowledge model for the original GUIDON system was the rule- 
based expen system, MYCIN. Consequently, the primary representation scheme for 
the domain knowledge was a production system. Clancey took full advantage of the 
characteristics of this representation scheme to enhance the tutorial effectiveness of 
the GUIDON system. He took advantage of the fact that structure and syntax of pro¬ 
duction rules makes them "human readable" and consequently, very useful in the in¬ 
structional process. In addition, because production rules were used the knowledge 
domain was modularized into a set of independent and finely grained concepts. Pro¬ 
duction rules were such an effective representation scheme that they were used as 
the basis for the other three components in the system. 

The knowledge in the tutor model, for example, is a represented by a collection 
of production rules which Clancey calls "t-rules". These t-rules, which numbered 
over 2(X), captured the procedural knowledge associated with GUIDON’S tutoring 
strategy and pedagogical style. These t-rules can be best described as meta-rules or 
meta-knowledge because they reasoned about, and work on, other rules in the sys¬ 
tem. (Clancey, 1986, p. 41) 

The student model in GUIDON also makes extensive use of both the MYCIN 
production system and other production rules. To model the stude.it, Clancey used an 
overlay model in which the system gave the student "credit" for partial solutions. 
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GUIDON is able to assign credit in such a manner because of the following features 
of the system: it generates an "approved solution" to each diagnosis problem before it 
presents it to the student and it uses another set of production rules (really a subset 
of the "t-rules") to compare the system’s solution with the student’s partial solu¬ 
tions. The system also keeps track of the student’s response history to better deter¬ 
mine his current knowledge state. 

The communication model in GUIDON, although not implemented as a sepa¬ 
rate module, is also based primarily on a production rules. The communication model 
can not be considered a separate module because it is tied directly to the tutor model. 
The "t-rules" which serve both to guide the student through the instruction, and diag¬ 
nose his current knowledge state, also serve to determine how information is present¬ 
ed to the student and how student input are interpreted by the system. These rules 
control the natural language discourse with the student. 

4. Power Distribution Tutor 

In the mid-1980’s J. R. Bourne and his contemporaries at the Center for Intelli¬ 
gent Systems at Vanderbilt University, implemented two ICAI systems which pro¬ 
vide instruction in engineering domains. The two specific domains which are 
addressed by these implementations are: (1) a hot water heating system, and (2) a 
power distribution system. Both systems have a number of interesting features, how¬ 
ever, in this section we will focus on the power distribution system tutor (PDST). 
(Bourne et al, 1988, pp. 213-226) 

The PDST system employs a sophisticated, interactive, graphical model of a 
power distribution plant. It is a "complete" tutoring system in which all four compo¬ 
nents of the generalized ICAI are present. An important difference between the 
ICAI’s discussed earlier and PDST is the approach that its designers took with the 
respect to the knowledge representation issue. Instead of depending on one primary 
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representation scheme, the designers of POST employed a variety of representation 
schemes in their system. The POST designers used both structured object and pro¬ 
duction system representation schemes throughout their application. 

The domain knowledge model in POST is a sophisticated model-based simula¬ 
tion of a power distribution system. The representation scheme that was used to de¬ 
velop the simulation was a structiu^d object representation. The domain knowledge 
lent itself well to this form of representation because the system is made up of numer¬ 
ous components, each of which can be modeled as distinct objects. Since each compo¬ 
nent is modeled as an object, the static, declarative information concerning each 
object and its relationship with other objects were stored together in one frame. In ad¬ 
dition, since many of the objects in the system are of the same type or class the sys¬ 
tem designers were able to organize the objects into an inheritance hierarchy. Still 
further, the dynamic, procedural information that is associated with each component in 
the system was attached to the component’s frame. The dynamic behavior of an ob¬ 
ject in this application is normally its response to changes in the system. (Bourne et 
al, 1988, pp. 213-226) 

The tutoring model in POST, referred to by the system’s designers as the 
Strategist, uses a production system as its primary representation scheme. This 
scheme was selected because it was determined that the knowledge which must be 
captured by the tutor model is best represented in the form of production rules. The 
system’s designers were attempting to capture human expertise in this component of 
their system and production rules are especially well suited for this purpose. 

The representation scheme that was used for the student model in POST was 
also a production system. The POST designers implemented a "bug" model to model 
the student’s current knowledge state. They took advantage of the modular nature of 
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rules and consequently each potential "bug" that the designers identified was cap¬ 
tured in a single rule. 

The communications model in POST is a sophisticated, interactive graphical in¬ 
terface. The system’s various components are displayed graphically and the user can 
affect the state of the system by pointing at, and selecting, components with a 
mouse. The designers of POST used a structured object representation to capture the 
knowledge in the communication model. This representation scheme was selected 
because each of the graphical images that are displayed represents an object in the 
system. 

C. SUMMARY 

Knowledge representation is clearly one of the most significant issues in the de¬ 
sign of ICAI systems. ICAI systems are generally very complex and consequently 
the designer of such systems must represent many different types and categories of 
knowledge within their systems. They must represent the following different types of 
knowledge within the four components of their systems domain knowledge, cognitive 
knowledge, interface knowledge and pedagogical knowledge. In addition, they must 
represent knowledge which falls into the following categories: declarative knowledge, 
procedural knowledge, and meta-knowledge. 

The preceding review of existing ICAI systems should give the reader an appreci¬ 
ation for the variety of approaches that ICAI designers have taken with regard to the 
issue of knowledge representation. In the SCHOLAR system, an associational- 
based representation scheme, a semantic network, was employed as the principle 
representation scheme. In BUGGY, a procedural-based representation scheme was 
used throughout. In GUIDON, a production system was employed to capture all of 
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the knowledge in the sytem. Finally, the POST system used both a production sys¬ 
tem and a structured object representation schemes. 
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V. APPLICATION DEVELOPMENT ENVIRONMENT 


A. INTRODUCTION 

We have designed two ICAI systems in the Knowledge Engineering Environment 
(KEE) on a Texas Instruments Explorer workstation. The development environment 
is described below for the reader to gain a basic understanding of the tools and facili¬ 
ties we used in the development of both applications. KEE terminology is also impor¬ 
tant to know for the later descriptions of the applications. 

B. TEXAS INSTRUMENTS EXPLORER 

The Explorer system is an advanced, single-user workstation that provides ex¬ 
tensive support for developing knowledge-based applications and for rapid prototyp¬ 
ing, It offers a flexible, interactive, and highly productive programming environment 
with run-time support for efficient execution of sophisticated programs. The explorer 
system offers the user the following benefits: 


(i) Natural manipulation of symbols that can represent abstract concepts using 
the Lisp language in a high-speed hardware architecture especially designed for 
symbolic processing; 

(ii) Abifity to create large programs without concern for memory allocation and 
deallocation, taking advantage of the system’s efficient incremental garbage col¬ 
lection and virtual memory management of up to 128 megabytes of virtual memory; 
and 

(iii) Transparent sharing of resources with a variety of computer systems 
through networking facilities. (Texas Instmments Incorporated, 1988, p. 1-1) 


The specially designed and microcoded Explorer system processors directly imple¬ 
ment the software run-time environment, providing fast execution of large programs 
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without sacrificing the dynamic nature of Lisp. The Explorer system is written entire¬ 
ly in Lisp and supports Common Lisp. 

C. KNOWLEDGE ENGINEERING ENVIRONMENT 

The Knowledge Engineering Environment (KEE) provides knowledge system de¬ 
velopers with a set of programming tools and techniques for building applications to 
represent, analyze, and reason about knowledge, and to construct application interfac¬ 
es. It is built upon Lisp and supports object oriented programming. The following 
sections describe features of KEE so the reader will have a basic understanding of 
KEE terminology presented in follow on chapters. 

1. Objects 

Since KEE is based upon the object-oriented programming paradigm, it con¬ 
tains a flexible and expressive firame system for representing and managing knowl¬ 
edge. The basis of the firame system is the object. Objects arc discrete data 
structures used to represent real world objects. Objects can be grouped tfUpther in 
class-subclass-instance hierarchies to logically organize objects in an application and 
to take advantage of inheritance. An object contains slots which describe attributes 
about the object. Slots are used to represent two kinds of information: descriptive 
and procedural. They can store numerical and textual data about the object as well as 
more complex information such as graphics structures, references to other objects, 
and procedural programs that can execute Lisp functions or begin rule chaining. A 
slot contaiiung procedural information is called a method. Methods are procedures 
with local state that specify the behavior of the object in response to messages sent 
to the object. 
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2. Inheritance 

Designers can describe a system by creating objects that act as templates for 
whole classes of objects. When an object is designated as a "child" of one or more 
objects, it inherits slots and default information from its ancestors. Inherited informa¬ 
tion can be added to or modified only as needed to differentiate the child object from 
its parents. 

3. Rules 

One way of presenting unordered, declarative knowledge in an ICAI system is 
through rules The rules either state new facts to the system and lei it determine the 
consequences of these facts (forward chaining), or ask the system about a particular 
goal and let it determine whether or not that goal can be deduced, given the facts that 
the system already knows (backward chaining). In KEE, the reasoning capability on 
rules is supplied through tools called Rulesystem3 and TellAndAsk. Rulesystem3 
provides forward and backward chaining capabilities and the means of controlling and 
debugging them. TellAndAsk integrates these capabilities with the larger frame sys¬ 
tem. 

In KEE, rules and rule classes are represented as objects whose attributes 
are defrned by Rulesystem3. Each rule is an object, and each rule object is a member 
of at least one rule class. In addition, KEE allows users to partition rules by grouping 
them into rule classes. This increases the system efficiency by reducing CPU time for 
pattern-matching routines and user maintenance time. Since rules and rule classes 
are represented as objects, the KEE frame system and interface is available for creat¬ 
ing and manipulating rules and rule classes. Additionally, since they are KEE ob¬ 
jects, rules can be manipulated and reasoned over like any other KEE object. 

KEE provides two types of rules for the designer: deduction rules and action¬ 
taking rules. Both types are needed depending upon whether the user requires mles 
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that perform deduction and rules that take some kind of action on the system objects. 
Deduction rules are pure theorem-provirg rules. They establish dependencies be¬ 
tween a conclusion and its premises. If the rules produce a contradiction to the set of 
facts that the system started out with, the original facts are inherently contradictory 
or the rules are in error. Action-taking rules, on the other hand, change the knowl¬ 
edge base of the application, for example, making an additional assumption or taking 
an action. Depending on where the change in the assumption set takes place, action¬ 
taking rules are either same world action rules or new world action rules. (Intellicorp, 
Inc., 1988, p. 1-3) 

4. Truth Maintenance System 

Dependencies can be set up between facts in a knowledge base, such that a 
particular fact is always true when one or more other supporting facts are also true. If 
a fact or assumption is no longer believed to be true, KEE’s Assumption-based Truth 
Maintenance System (ATMS) makes sure any facts contingent upon the belief are re¬ 
tracted from the knowledge base. 

5. KEEworlds 

KEE provides a multiple worlds facility called KEEworlds that enables a user 
to assert a collection of facts into a single context, called the background, which can 
be used as a basis for the creation of additional worlds containing somewhat different 
facts and assumptions. KEEworlds is useful for modeling and exploring different hy¬ 
pothetical situations that might arise in a knowledge base. A new world represents 
an alternative state or new context of a knowledge base. 

6. Backward and Forward Chaining 

Rules designed in KEE may be linked together into chains, by matching the 
premise of one mle to the conclusion of another rule or by matching the conclusion of 
one rule to the premise of another rule. In this way, a rule can be used to help prove 
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or derive another rule. Backward chaining (also called goal-driven reasoning) at¬ 
tempts to establish the conclusion of a rule by seeing if the rule’s conditions can be 
established using facts in the system or by triggering other rules. Forward chaining 
(also called data-driven reasoning) starts with a set of facts and matches them to the 
premises of a rule. If the premises are satisfied, the rule’s conclusions are added to 
the knowledge base and may be used to draw additional facts. 

7. TellAndAsk 

TellAndAsk is an English-like language that can be used with KEE. It can be 
used for a variety of purposes such as interacting with knowledge bases, writing 
rules, creating justifications, and putting facts into worlds. TellAndAsk is a language 
with a syntax similar to English and provides a way of making statements about: rela¬ 
tionships between units, values of slots, and values of facets. 

8. KEEpictures 

The KEEpictures environment is an object-oriented graphics toolkit that en¬ 
ables designers to construct images or graphic systems, interfaces, and end-user ap¬ 
plications. Its intended uses range from simple graphical displays to animation. 
KEEpictures provides a set of standard picture classes for picture construction. 
These include arcs, axes, box. strings, bitmaps, circles, dials, lines, and rectangles. 
Each of these primitives can be shaped, enlarged, shrunk, and altered in a variety of 
ways. Pictures can be combined to form larger, composite pictures. Users can also 
draw their own pictures using bitmaps. 

9. Activelmages 

KEE’s Activelmages package provides a variety of graphic displays for both 
viewing and modifying slot values in KEE objects. These graphic images can be inte¬ 
grated into an application as an attractive interface to the system. They also can be 
used during application development as a convenient display aid for debugging pro- 
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grams. There are over twenty different images, including bargraphs, histograms, ther¬ 
mometers, switches, push buttons, and plots. 

10. Active Values 

Active values are KEE objects which allow a designer to specify actions to 
happen when slots are accessed or modified. They provide the facility to cause side- 
effect behavior when accessing or modifying data in a knowledge base. By attaching 
an active value to a slot, the designer can specify that a particular action should occur 
every time that slot’s value is accessed or modified. 

D. KNOWLEDGE REPRESENTATION IN KEE 

KEE supports various knowledge representation schemes including structured ob¬ 
ject representations, procedural representations, production system, associational 
representations, and formal logic-based representations. 

Since KEE is based upon a frame system for representing and managing knowl¬ 
edge, it is obvious that KEE supports objects as a form of structured object represen¬ 
tations. Both declarative and procedural knowledge can be represented in slots of 
objects. 

Procedural knowledge can be represented in KEE in a procedural representation 
scheme. An object created solely for representing a procedure contains only one or 
more methods, no slots with descriptive information. Such an object explicitly repre¬ 
sents procedural knowledge. 

KEE explicitly supports the use of production rules through its RulesystemS 
knowledge base. Procedural knowledge can be represented by production rules. Rea¬ 
soning can be accomplished by backward or forward chaining. 
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Semantic networks can be created, although KEE does not explicitly support their 
creation. Any relationships within knowledge in an associational representation 
schemes must be designed by the user using slots and methods in objects. 

KEE’s TellAndAsk language provides a means of representing knowledge in a 
formal logic-based representation scheme. Knowledge is represented as declarative 
facts in the form of English-like statements called well-formed-formulas (wff). WfTs 
can be added to, retrieved from, or deleted from a knowledge-based system. Wff’s 
with or without variables evaluate to true, false, or unknown. KEE also supports the 
use of deduction rules to represent generalized dependencies between facts, to create 
constraints, and to control search. 
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VI. MAP READING TUTOR 


A. INTRODUCTION 

The Map Reading Tutor (MAPTR) is an ICAI for teaching U.S. Army soldiers the 
common skills tasks required for proficiency in reading and using a military map. Such 
skills are necessary for conducting military operations. A potential student of the 
system can be unfamiliar with the material or proficient at some or all of the tasks 
which the system teaches. The system behaves as a tutor who teaches a lesson plan 
of tasks. The lesson plan is developed either from student input or based upon the 
system’s diagnosis of the student’s knowledge state. Text and graphics are present¬ 
ed to the student in a predetermined sequence for each concept contained in the task. 
At the completion of a task, the tutor tests the student on his understanding of the 
material. Remedial training is provided for tasks which the student is deficient. 

B. THE TASK; MAGNETIC AZIMUTH 

The system currently contains knowledge to teach the task: magnetic azimuth. 
The azimuth is the most common military method to express direction. Determining 
and using a magnetic azimuth is a fundamental skill without which it would be difficult 
to plan and conduct military operations. The instruction provides the soldier with 
knowledge about azimuths, the three different norths, the declination diagram, and the 
conversion of azimuths from grid to magnetic, and vice versa. 

The instruction begins with the definitions of the three norths: true north, magnetic 
north and grid north. The soldier must understand that magnetic readings obtained by 
a magnetic compass indicate the direction to the north magnetic pole; while grid north 
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is the north that is established by using the vertical grid lines on the military map. 
Next, the declination diagram is introduced. The declination diagram is a part of the 
marginal information on all military maps. It shows the angular relationship among 
the three norths. The soldier is then taught the concept of azimuth conversion using 
the grid-magnetic (G-M) angle found in the declination diagram. The G-M angle is 
the angular size that exists between grid nonh and magnetic north. Mastering this 
concept is essential for plotting a magnetic azimuth on a map or determining a mag¬ 
netic azimuth from a map. 

C. MAPTR ARCHITECTURE 

MAPTR has the same general components of a typical ICAI system. The func¬ 
tions of each component are presented below. 

1. MAPTR Domain Knowledge Model 

The domain knowledge model contains knowledge about the concepts of azi¬ 
muths, the three norths, the declination diagram, and azimuth conversion. It is used 
in the generation of lesson plans and to evaluate the soldier’s performance. The con¬ 
cepts are captured in the form of text and graphics. Training modules contain multiple 
concepts in a predefined sequence for instruction. The knowledge is programmed for 
three training modes: review, train, and retrain. Each concept is represented in three 
different ways to satisfy a soldier’s requirement to review, train, or retrain the sub¬ 
ject. Additionally, main concepts and tasks are evaluated. The domain knowledge 
model also includes the proficiency thresholds of each task for the three training 
modes. 

The domain knowledge model is organized as a taxonomy of tasks. Each task 
has subtasks, supertasks, and a training module associated with it. A training mod¬ 
ule consists of the major concepts of a task. The major concepts of a training module 
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are represented as submodules. A training submodule contains the declarative or 
procedural knowledge associated with a particular concept. The knowledge represen¬ 
tation scheme used in this system to represent both types of knowledge in the knowl¬ 
edge model is a form of structured object representations called objects. Additionally, 
we incorporated the objects into a form of associational representation scheme called 
a semantic network. 

The taxonomy of tasks is a hierarchy of objects containing many slots. Each 
object contains slots identifying the task’s supertasks and subtasks, the prerequi¬ 
sites for learning the task, the time period requiring review or training of the task, the 
proficiency threshold, and the training module for the task. The supertasks, subtasks, 
and prerequisites slots of a task add a relational attribute to the object. A task may 
be a supertask, subtask, and a prerequisite of another task. The objects that repre¬ 
sent the tasks are considered nodes of the semantic network. Tlie slots contain the 
associative links to other objects and are considered the arcs of the network. 

The purpose of a training module is to organize the concepts of a task depend¬ 
ing upon the training mode: review or train. It embodies the sequence in which the 
concepts of a task are presented. The presentation sequence of the main concepts of 
a task depends upon whether the soldier requires reviewing or training. A training 
module consists of a group of objects representing each major concept in the task. 
The objects have two slots: review and train. When the training mode is determined, 
the appropriate slot of each major concept is accessed to acquire the correct set of 
training submodules. 

The training submodules are a group of objects that contains the knowledge of 
a concept. The text and graphics that explain and illustrate a concept are different de¬ 
pending upon >vhether the soldier is reviewing or learning the concept. Hence, there 
are two objects for every concept, one for each training mode. Each object has a slot 
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containing a list of objects that contain the text and graphics associated with the con¬ 
cept. 

A concept may be composed of three types of knowledge: declarative, proce¬ 
dural and heuristic. Examples of each type are shown in Figures 3 and 4. The knowl¬ 
edge model contains a group of objects that correspond to all of the declarative, 
procedural, and heuristic knowledge in the task. Each object has two specific knowl¬ 
edge slots for the concept which it encapsulates. One of the slots contains a refer¬ 
ence to a graphical representation of the fact; the other slot contains the explanation 
of the fact. 


Facts: 

• There are three kinds of norths: true north, 
magnetic north, and grid north. 

• Grid north is the north that is established by 
using the vertical grid lines on the map. 

• The angle between grid north and magnetic 
north is called the Grid-Magnetic Angle. 

• All military maps contain a declination 
diagram which illustrates the relationship 
between the three kinds of norths. 

• The lensatic compass is used to measure 
the base direction of magnetic north. 


Figure 3 • Declarative Knowledge 


44 










Figure 4 - Procedural and Heuristic Knowledge 


For example, we created an object called FRAME.THREE.NORTHS to 
teach the concept about the three kinds of norths. The object has two slots, MYPIC- 
TURE and MYTEXT. Figure 5 shows the value of the slot MYTEXT which de¬ 
scribes the concept. Figure 6 shows the value of the slot MYPICTURE which is a 
pointer to an image created to illustrate the concept. Two additional slots contain in¬ 
formation for use during student evaluation of the task. A slot called RE- 
SPONSE.LIST contains the possible solutions to a problem which is posed to the 
soldier during an evaluation. The solutions are displayed in a menu for the soldier’s 
selection. The other slot is called CORRECT.RESPONSE and contains the solution 
to the corresponding problem. The use of these two slots is explained in the section 
which describes the tutor model. 
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When we define azimuth we say it is measured from the 
base direction of north. In this world of ours we have three 
norths and you see them graphically represented in the 
declination diagram of your map. Check any military map and 
you’ll see that the three norths are: 

• TRUE north - a line from any position on the earth’s 
surface to the geographic north pole. True north is 
symbolized by a line with a star at the apex. 

• MAGNETIC north - the direction in which the magnet¬ 
ic arrow of the magnetic compass points. Magnetic 
north is symbolized by a half arrowhead at the apex of 
a line. 


• GRID north - the north that is established by grid lines 
on the map. Grid north is symbolized by the letters 
GN at the apex of a line. 


Figure 5 - Text 
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Figure 6 • Graphics 
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All declarative knowledge is represented in this manner. Procedural knowl¬ 
edge is decomposed into primitive operations. Each operation is again represented 
using a form of strucmred object representations called objects. A procedure then is 
presented as a sequence of primitive operations. 

2. MAPTR Tutor Model 

The tutor model manages what instructional material the system presents and 
how and when it should present it. Using the student model and knowledge model, 
the tutor model adaptively constructs an individual lesson plan for teaching the sol¬ 
dier. First, it assesses a soldier’s knowledge state by comparing the proficiency 
threshold of a task to the soldier’s proficiency of that task and then checking the date 
of proficiency. From this, the tutor model determines the tasks to teach and the train¬ 
ing modes to use for the tasks. Then it presents displays of information and graphic 
instruction screens covering the tasks, concepts, and evaluations in the lesson plan. 
Finally, the tutor model updates the student model upon completion of evaluations. 

The type of knowledge which the tutor model represents is procedural knowl¬ 
edge. We used a procedural representation scheme to represent the procedural 
knowledge. Many of the objects described in the knowledge model contain methods 
that represent pi_.s of the procedural knowledge. Each object that represents a task 
in the taxonomy contains a method called TEACH that formalizes all of the tutor’s 
procedural steps for teaching that task. The procedure in the TEACH method con¬ 
tains many subprocedures that are reflected as methods of other objects in the knowl¬ 
edge model. Such methods include getting the proficiency thresholds of the task for 
each training mode; obtaining the appropriate training modules depending upon the as¬ 
sessed training mode; and displaying text and graphics. 

The TEACH method is a recursive Lisp function that is a method of every task 
in the knowledge model. The procedure is described as follows. When a task is se- 
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lected to be taught, either by the soldier or the system, the TEACH method is in¬ 
voked. The method retrieves the training modules, prerequisites, and subtasks of the 
task for assessment. If there are prerequisites then the method requests from the 
student model the soldier’s proficiency in each task in the prerequisite list. If the sol¬ 
dier is not proficient or needs to review any task on the prerequisite list then the 
TEACH method activates that task to teach the soldier, otherwise, the method 
checks the list of subtasks. The method repeats the same actions on the subtask list 
as with the prerequisite list. If no subtasks exist or the soldier is proficient in the 
subtasks then the method checks the training module list for the current task. The 
method requests from the student model the training mode in which to teach the sol¬ 
dier. Then the TEACH method activates a method in the appropriate training sub- 
module to show its list of objects that contain the instructional displays. These 
objects contain a method that displays its text and graphics to the screen. 

The last item on the training module list is an evaluation of all the material cov¬ 
ered in the training module. Soldier input during an evaluation is through a menu sys¬ 
tem. The tutor model compares soldier responses to the value of the 
CORRECT.RESPONSE slot of the appropriate display object, assesses the soldier’s 
proficiency, and provides feedback. If the soldier is proficient then the tutor tells the 
current soldier’s student model to update itself; otherwise, the tutor activates a meth¬ 
od in the training submodule for retraining to show its list of display objects. After re¬ 
training is completed, the tutor repeats the evaluation process. If the soldier is still 
deficient, the tutor records the information for later feedback. 

3. MAPTR Student Model 

The student model reflects the soldier’s proficiency in the task. It receives 
performance evaluations with respect to the task the soldier is expected to acquire 






from the tutor model. These evaluations are permanently stored for analysis by the 
tutor model to determine lesson plans. 

The student model consists of declarative knowledge about the soldier’s state 
of knowledge. A form of structured object representations called objects is used to 
represent the declarative knowledge. When a new soldier enters the program, three 
objects are created using his social security number (SSN) that form a composite ob¬ 
ject. Figure 7 illustrates an inheritance hierarchy of several KEE objects which form a 
student model for two students. The objects containing the SSN, 111-11-1111, form 
a composite object that constitutes the student model for the soldier with that particu¬ 
lar SSN. These three objects and their various slots will be described in detail. 

The first object called 111-11-1111 contains five slots. Two slots contain 
pointers to the other two objects in the composite object, 111-11-1111.PROF.DATA 
and 111-11-llll.ADMIN.DATA. The other three slots are methods for assessing 
the soldier’s knowledge state, for recording the soldier’s proficiency during a training 
session, and for deleting a student record. 

The second object called 111-11-llll.ADMIN.DATA currently contains three 
slots for recording administrative data: FIRST.NAME, LAST.NAME and SEX. This 
object could contain as many slots as needed to record all administrative information 
required. 

The third object called lll-ll-llll.PROF.DATA currently contains a large 
number of slots, most of which represent each task in map reading. These slots con¬ 
tain a value representing the soldier’s current proficiency in the respective task. Four 
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additional slots are methods for initializing this object at creation and for assisting the 
methods in the 111-11-1111 object. 


^lll-11-llll.ADMIN.DATA 

,STUIJENTADMIN.RECORDS 


' 222-22-2222. ADMINDATA 
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Figure 7 • MAPTR Student Model 
4. MAPTR Communication Model 

This model provides an interface to the soldier for instructions, text and graph¬ 
ics, system responses, and soldier input. Windows and pop-up menus arc provided. 
All student input is accomplished by a mouse. The communication model for MAPTR 
contains procedural knowledge. We used a procedural representation scheme to rep¬ 
resent the procedural knowledge. 

The interface consists of an input window, an output window, viewports, and 
menus. Figure 8 illustrates a typical screen during a tutoring session. We designed 
window and menu methods that programmatically created the input and output win¬ 
dows and the menus. We created a standard KEE typescript window that is dis¬ 
played for the user to input administrative information and for the system to display 
system instructions. We created a standard KEE output window that displays all 
text for domain knowledge instruction. We also created numerous viewports for dis- 
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playing graphical images of concepts in support of the textual instruction. We also cre¬ 
ated pop-up menus to accept input from the user. The soldier can select the tasks to 
be taught or enter an answer during an evaluation using these menus. The KEE sys¬ 
tem contains built-in functions for implementing the window and menu methods we 
designed. 



Figure 8 • MAPTR Interface 

D. SAMPLE TUTORING SESSION 

The interactions between the four models is described through the course of a typ¬ 
ical tutoring session. When a soldier logs into the system and provides his SSN, the 

























student model checks for a student record matching the SSN. If one does not exist, 
the student model creates a composite object representing the new soldier’s student 
record. The soldier is then presented a sequence of menus for the soldier to choose 
the desired task to be taught. The tutor model interacts with the knowledge model 
and student model to determine (1) if any prerequisite tasks need to be presented, 
and (2) the mode of instruction. The knowledge model interacts with the communica- 
don model to display the text and graphics that constitute the instruction for the task 
and to present an evaluation at the conclusion of the instruction. Through the course 
of instruction, the tutor model checks for required subtasks. If subtasks exist, the tu¬ 
tor, student, and knowledge models repeat the process of determining the mode of in¬ 
struction and presenting the instruction and evaluation. From an evaluation, the tutor 
model determines if the soldier is proficient at a task. If not, the tutor model changes 
the instruction mode and activates the knowledge model to retrain the soldier. Other¬ 
wise, the soldier can chose another task to be taught. Screen displays of a sample tu¬ 
toring session is provided in Appendix B. 

E. EXTENSIONS 

Additional tasks which a soldier must know to be proficient at reading a map can 
easily be incorporated into MAPTR. The current taxonomy of tasks is structured to 
include all of the additional tasks. The domain knowledge model could be expanded to 
include the text and graphics needed for instruction of additional tasks. The student 
model could be updated to also include the additional tasks. The TEACH method in 
the tutor model would execute the tutoring process for additional tasks without any 
modification. With the inclusion of all tasks, MAPTR would be a suitable ICAI sys¬ 
tem for assisting trainers in the instruction of map reading skills to soldiers. 






VIL PILOT EMERGENCY PROCEDURE TUTOR 


A. INTRODUCTION 

The Pilot Emergency Procedure Tutor (PEPTR) is an ICAI for teaching F-4 pilots 
how to detect, analyze, plan and perform appropriate actions to deal with on-board 
emergencies. It is designed to be a training assistant for pilots to use in maintaining 
their skills at solving in-flight emergencies. PEPTR has two modes of operation: a re¬ 
action mode and an instruction mode. In the reaction mode, the student can freely 
change the state of the aircraft to learn what in-flight emergencies are caused by vari¬ 
ous aircraft states and to learn which changes lead to a solution. While in the instruc¬ 
tion mode, the student engages in a tutoring process that provides instruction and 
evaluation of a predetermined in-flight emergency. PEPTR provides the user with an 
interface containing switches and dials that represent aircraft systems and are used 
to define the initial state of the aircraft or change its state depending on the mode of 
operation. The expen model in PEPTR is invoked either by the system or the user 
depending upon the mode of operation to diagnose and determine the correct solution 
to an in-flight emergency. The expen model in PEPTR performs diagnosis of the situ¬ 
ation utilizing rules that define aircraft system behavior. PEPTR checks the various 
switches and circuit breakers that are accessible to it and creates a list of actions that 
should be performed in order to overcome the emergency situation. Execution (by the 
user) of the advised actions involve altering switch settings. These actions will affect 
the state of the aircraft and may lead to resolution of the problem. 
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B. F-4 DESCRIPTION 

The F-4 fuel system consists of 5 fuel tanks: a fuselage tank (consisting of 6 sep¬ 
arate cells with approximately 89(X) lbs of total capacity), an internal wing tank 
(consisting of 2 separate cells with approximately 4300 lbs total capacity), two exter¬ 
nal wing tanks (2500 lbs capacity each), and an external centerline tank (with 4000 
lbs capacity). The fuel is fed to the two aircraft engines from die integral fuselage 
tank, which in turn is fed from other tanks until they become empty. 

The fuel to the fuselage tank is transferred using air pressure that is provided by 
the engines. Except for certain situations (e.g., take-off and landing) the fuel tanks 
are pressurized and the fuel is transferred. 

The fuel flow to the fuselage tank is regulated by the tank’s fuel level valves in 
such way that, as long as there is fuel in other tanks, the fuselage fuel tank is kept 
full. For different reasons (e.g., gravity center considerations, landing stress, etc.), 
during most of flight cycles internal wing and external fuel tanks will not transfer fuel 
to the fuselage tank in concurrent fashion. Their fuel transfer is determined by an Ex¬ 
ternal Tank Transfer Switch that is operated directly by the aircraft pilot. The pilot is 
provided with additional switches (e.g.. Fuel Dump Switch) to control the operation of 
the fuel system in normal and emergency conditions. 

The F-4 aircraft is equipped with an in-flight refueling system that allows mid-air 
refueling of the aircraft. This system uses the same fuel lines and valves as the regu¬ 
lar fuel system, and it allows selective refueling of internal and external fuel tanks. 
Although the F-4 fuel system is designed to minimize pilot’s work-load under normal 
conditions, it requires some "switch toggling" for its regular operation, and more effort 
for diagnosing and rectifying fuel system malfunctions. 
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C. THE TASK; FUEL SYSTEM EMERGENCY PROCEDURES 

PEPTR is designed to deal with malfunctions of several aircraft systems (e.g., fu¬ 
el, hydraulic, electrical, engine, etc.); however, the current scope of the system deals 
only with some of the fuel system failures and emergencies. The student learns about 
the fuel system components and their operations and how the state of the aircraft af¬ 
fects fuel system emergencies. Fuel system emergency procedures are decon^sed 
into four categories: fuel boost pump failure, fuel transfer failures, failed open d^uel 
valve during air refueling, and air refueling juselage tanks. Each category may com¬ 
prise of one or more emergency conditions which contain a procedure for correcting the 
problem. For example, the category, fuel tranter failures, contains four emergency 
conditions, one of which is titled internal wing fuel fails to tranter. This emergency 
condition contains the following procedure that the pilot must follow to correct the 
problem. 

Check the following switch and circuit breaker positions: 

1. External transfer switch - OFF 

2. Internal wing transfer switch - NORMAL 

3. Refuel probe switch - RETRACT 

4. Internal wing transfer control circuit breaker - IN 

5. To ensure wing tank pressurization: 

Wing transfer pressure switch - OVRD TRAN 
(continue in level flight for 30 seconds) 

This procedure identifies what switches apply to this emergency condition and the 
correct positions for each switch. If the pilot diagnosis this emergency condition, then 
he must follow this procedure to determine if the cause is incorrect switch positions. 
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If so, then he must coirect the switch positions in order to eliminate the emergency 
condition. A student can be tutored on this emergency condition and all other emer¬ 
gency conditions that comprise each category. Additionally, single or multiple emer¬ 
gency conditions can be presented* to the student 

D. THE ARCHITECTURE 

The major components of PEPTR are also the same as the general components of 
an ICAI system. The functions of each component are presented below. 

1. PEPTR Domain Knowledge Model 

The domain knowledge model consists of two major components: the aircraft 
model and the expert model. The aircraft model consists of knowledge representing 
the physical characteristics and operating methodologies of the system. It employs a 
number of physical components of an aircraft. Each component assumes a small num¬ 
ber of states. Briefly, the components range in complexity from a cockpit or fuel sys¬ 
tem to a switch or fuel gauge. The states of components include such things as 
switch positions and fuel tank levels. 

The expert model consists of the fuel system categories and emergency condi¬ 
tions along with each procedure. This part of the program provides the following func¬ 
tionality: diagnosis of system emergencies, and development of solutions to these 
problem. The component that the expert model interacts with depends upon the cur¬ 
rent user’s mode. If the system is in the reactive mode then the expert model inter¬ 
acts exclusively with the communication model. While in the instruction mode the 
expert model interacts with both the tutor and communication models. Information in 
the expert model was derived from the Naval Air Training and Operating Procedures 
Standardization Program (NATOPS) flight manual for F-4 operators and by inter¬ 
viewing known experts. 






Declarative and procedural knowledge arc both represented in the knowledge 
model. The model of the aircraft contains: (1) declarative knowledge about the air¬ 
craft description and about the state of the aircraft, and (2) procedural knowledge that 
changes the state of the aircraft. The expen model contains procedural knowledge re¬ 
quired to reason and solve problems about the domain, 
fl. PEPTR Aircraft Model 

The aircraft model is a representation of a physical aircraft The state of 
the aircraft can be changed by manipulating the model. Reasoning about the state of a 
physical aircraft can be accomplished by using the model. The knowledge representa¬ 
tion scheme used to represent the declarative and procedural knowledge in the air¬ 
craft model is a form of structured object representations called objects. The aircraft 
is designed as a composite object made up of different components. We represent 
components of an aircraft using objects. An object has slots containing attributes that 
describe the aircraft component and information about its relationship with other com¬ 
ponents. For example, an object called TEST-F4 has three slots, each containing 
pointers to other objects that represent three major components of the aircraft: cock¬ 
pit, electrical system and fuel system. TTie cockpit object also contains three slots 
with pointers for values to objects that represent various panels in the cockpit: circuit 
breaker panel, electrical panel and fuel system panel. The fuel system panel object 
has slots that reference objects that represent all of the switches, gauges, and lights 
in the panel. The objects that represent the switches have a POSITION slot that con¬ 
tains a value that indicates the state of the switch. 

We used a procedural representation scheme to represent constraint 
knowledge, a type of meta-knowledge. Constraint knowledge in the aircraft model in¬ 
cludes the effect of an object on one or more other objects. For example, changing the 
amount of fuel in the tanks effects the rate of fuel change in the aircraft model. There- 
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fore, we attached active values to the slots that represent the fuel anx>unt in the vari¬ 
ous tank objects. The active values ensured that the value of the ^el rate of change 
slot changed appropriately when the user modified the amount of fuel in the tanks. 
For each active value, we created a separate object with a method for updating the 
rate of fuel change in the aircraft. Since the model depicts an aircraft in a snapshot of 
time, the user cannot determine the rate of fuel flow in the same manner as in a real 
aircraft; that is, by comparing the amount of fuel between two gauges over time. 
Therefore, we display to the user a constant value that declares the fuel rate of 
change during a training session. There are certain rules and procedures that deter¬ 
mine fuel rate of change just from the amount of fuel in the various fuel tanks. We 
have represented those procedures in active values. Therefore, whenever the user 
changes the fuel amounts in tanks, the active values are activated in order to update 
the fuel rate of change. 

b. PEPTR Expert Model 

The expert model captures the knowledge that a human expert uses to di¬ 
agnose problems and determine solutions in an F4 aircraft. The knowledge represen¬ 
tation scheme we used to represent this procedural and heuristic knowledge about 
the aircraft model was production rules. 

(1) Production Rules. We chose production rules as the knowledge repre¬ 
sentation scheme for several reasons. Production rules provide modular representa¬ 
tion of knowledge, skills and problem-solving methods. They encapsulate a piece of 
domain knowledge expertise. From a designers standpoint, this modularity reduces 
complexity by allowing incremental construction of the application, simplifies debug¬ 
ging efforts, and enhances extensions and modifications because rules can be added, 
deleted, or modified independently of each other. Production rules offer a uniform rep¬ 
resentation of knowledge to the designer or to another part of the system. The knowl- 
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edge is encoded in a rigid structure that is not imposed in a semantic net or procedural 
representation scheme. Production rules provide a namral form of representing 
knowledge. Human experts often explain their expertise as a matter of what to do in 
a certain situation (Barr and Feigenbaum, 1982, pp. 194-95). Additionally, production 
rules is a beneficial scheme because the information from the aircraft model needs to 
be combined opportunistically to achieve different diagnoses each time the expert 
model is invoked. 

(2) Inference Engine. After choosing production rules to represent this 
knowledge, we needed to choose an inference engine. The term inference engine re¬ 
fers to the mechanism used to draw conclusions from the rules in the expert model 
and the data in the aircraft model. Since the KEE system provides forward and back¬ 
ward chaining as an inference engine for applications, we chose to use one for the rea- 
sorung process in PEPTR. First, we chose backward chaining to diagnose a problem 
because there are a small number of diagnoses that can be determined from a large 
set of facts. We originally chose forward chaining to determine the solution because 
there was one fact (the diagnosis) and a multitude of possible solutions. We used 
the KEE system facility KEEworlds to create new worlds to hypothetically reason 
about solutions and prevent affecting the original aircraft state. Upon implementation, 
we found that forward chaining had a major drawback. Rules were invoked in an ex¬ 
haustive breadth-first search because the KEE system supports parallel reasoning 
and creation of new worlds. The combinatorics of this approach made it inefficient in 
practice, because hundreds of new worlds were created to reach all of the possible so¬ 
lutions. We realized that we needed the expert model to determine only one solution 
to a problem instead of finding all possible solutions. Therefore, we redesigned our 
solution rules and switched to backward chaining. This greatly reduced the number of 
new worlds created and increased the efficiency of the system. 
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(3) Diagnosis and Solution Rules. The user can invoke the expert model 
by mousing a button on the screen. This button is attached to a method of an object 
This method queries the expert model for the problem. If the expert model identifies a 
problem, the method then queries the expert model for the solution to the problem. 
During this process, the method displays information to the user concerning the prob¬ 
lem and the solution. The rules were written using the KEE system’s TellAndAsk 
language. They are partitioned into several rule classes. Two major classes of rules 
are diagnosis rules and solution rules. 

Diagnosis rules are used for diagnosing problems in the aircraft. Currently, 
this rule class contains rules for diagnosing fuel system problems. It is partitioned in¬ 
to rule subclasses that have different roles during the reasoning process. Figure 9 
shows the classes and rule instances of diagnosis rules currently in our expert model. 


/ FUEL.BOOST.FAILURE.NEW 
|FUEL.PROBLEM.RULES FUEL.TRANS.PROBJJEW 
I '^OTOER.FUEL.PROB 


/ CENTERLINE.TRANS.PROB 

/ 

,FUEL.TRANS.PROB.RULES (— EXT.WING.TRANS.PROB 


' INT.WING.TRANS.PROB 


EMERGENCY.DIAGNOSIS.RULES 


‘ OTHER.FUEL.PROBLEMS.RULES 


.,.'FUEL.LEAKJNT 


'REVERSE.TRANSJNT 


'TOP.LEVEL.DIAGNOSIS.RULES- START 
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The method explained earlier that invokes the expert model starts the 
backward chainer by quwying the rule called START of the rule class 
TOP.LEVEL.DIAGNOSIS.RULE. This rule queries the rules in the rule classes that 
represent the major types of emergency problems such as fuel, electrical, fire, and hy¬ 
draulic. Since the expert model currently contains only knowledge of fuel system 
problems, the START rule backward chains using only the rules in the rule class 
called FUEL.PROBLEM.RULES. This class of rules are intermediate rules created 
to reduce the difficulty in keeping track of evMything necessary for each rule. Interme¬ 
diate rules represent generalizations about a group of facts, thereby reducing redun¬ 
dancy and simplifying rules (Rowe, 1988, p.l30). These rules each represent a 
specific type of fuel emergency problems. For example, one type of fuel problem oc¬ 
curs when their is a a fuel transfer problem in the fuel system. Another type exists 
when a fuel boost pump fails. Hence, these rules try to identify the type of fuel prob¬ 
lem. They do so by doing further backward chaining. For example, the intermediate 
rule called FUEL.TRANS.PROB.NEW queries all of the rules in the rule class FU¬ 
EL. TRANS.PROB.RULES. These are the primitive rules which determine the specif¬ 
ic problem, if one exists. These rules contain multiple premises of two types. One 
type of premise checks the state of the aircraft, the other type checks facts assened 
in the knowledge base. Checking the state of the aircraft involves a premise of a diag¬ 
nosis rule looking at cenain slot values of those objects in the aircraft model that can 
cause the problem corresponding to the conclusion of that diagnosis rule. Sometimes 
the state of an aircraft component applies to multiple problems. In this case, the con¬ 
ditions for all the applicable problems must be checked. This leads to the second type 
of premise. Checking facts in the knowledge base involves invoking backward chain¬ 
ing on a different class of rules from within backward chaining. Thus, a premise of this 
type invokes backward chaining on the rule class that contains the rule for determin- 
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ing one of the applicable problems and checks the knowledge base to see if that prob¬ 
lem is asserted in the knowledge base. If all the premises of a diagnosis rule are sat¬ 
isfied then the diagnosed problem is asserted into the knowledge base. Figure 10 
shows examples of a diagnosis rules from each rule class. 

The solution rules are used to determine the solution to the problem if one 
exists. They are also partitioned into several smaller rule classes for the same rea¬ 
sons that the diagnosis rules are partitioned. The same method that invokes the 
backward chainer to diagnose a problem also invokes the backward chainer on a spe¬ 
cific rule class of the solution rules. The process of determining the solution is con¬ 
ceptually the same as for diagnosing the problem. Intermediate rules are used in the 
process. Another class of rules determines the operations which the user must imple¬ 
ment to change the state of the aircraft and asserts this as a fact into the knowledge 
base. 
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START Rule 

((IF (OR (FIND (TEXT (THE FUGHT.CONTROLJROBLEM IS ?PROB))) 

(FIND (TEXT (THE HYDRAUUC.PROBLEM IS 7PROB))) 

(FIND (TEXT (THE EL£CTRICAL.PROBl£M IS 7PROB))) 

(FIND (TEXT (THE FIRE.PROBLEM IS 7PROB))) 

(FIND (TEXT CTHE FUEL PROBLEM IS 7PROB)) USING FUELJ>ROBL£MJlULES)) 

THEN 

(TEXT (THE SYSTEM PROBLEM IS 7PROB)))) 


FUEL.TRANS.PROB.NEW Rule 

((IF (FIND (TEXT (THE FUEL TRANSFER PROBLEM IS 7FUEL.PROB)) 
USING FUEL.TRANS.PROB.RULES) 

THEN 

(TEXT (THE FUEL PROBLEM IS 7FUEL.PROB)))) 


INT.WING.TRANS.PROB Rule 

((IF (USP (> (THE FUEL OF TEST-FUEL.QU AN JND.CNTR) 

(THE FUEL OF TEST-FUEL.QUANJND.TAPE))) 

(FIND (EQUAL (THE RATE.OF.CHANGE OF TEST-FUEL.QUANJND.CNTR) 

(THE RATE.OF.CHANGE OF TEST-FUEL.QU AN JND.TAPE)) USING NO.RULES) 
(USP (< (THE FUEL OF TEST-FUEL.QU AN JND.TAPE) 

(THE MAXFUEL OF TEST-FUEL.QUAN.IND.TAPE))) 

(CANT.FIND 
(FIND (TEXT 

(THE FUEL TRANSFER PROBLEM IS CENTERLINE.TRANSFER.PROBLEM)) 
USING FUEL.TRANS.PROB.RULES)) 

(CANT.FIND 
(FIND (TEXT 

(THE FUEL TRANSFER PROBLEM IS EXT.TRANSFER.PROBLEM)) 

USING FUEL.TRANS.PROB.RULES)) 

THEN 

(TEXT (THE FUEL TRANSFER PROBLEM IS INT.WING.TRANSFER.PROBLEM)))) 


Figure 10 - Examples of Diagnosis Rules 
2. PEPTR Tutor Model 

The tutor model manages the training session through close coordination with 
the student, domain knowledge and communication models. At the beginning of a 
session, the tutor interacts with the student model to determine the in-flight emer- 
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gcncy which should be presented to the student. If the student is known to be defi¬ 
cient at solving the problem, then the tutor model interacts with the domain knowl¬ 
edge model to present instruction on the in-flight emergency. When all instruction is 
completed, the mtor model interacts with the domain knowledge model to present an 
in-flight emergency for the student to solve. When the problem is introduced, the tu¬ 
tor invokes the expert model to determine the correct solution. Through the course of 
the problem solving session, the tutor model accumulates student responses. It then 
gives the student model the solution and student responses for the student model to 
compare and update the student’s knowledge state appropriately. Finally, the tutor 
model interacts with the domain knowledge and communication models to provide 
feedback to the student. 

The tutor model of PEPTR contains procedural knowledge associated with a 
tutor. We used a procedural representation scheme to represent this procedural 
knowledge. To implement the tutor model, we created an object which contains one 
method called TEACH.F4 that represents the procedural tutoring process. The 
TEACH.F4 method consists of two main procedures. 

The first procedure is outlined as follows. First, the method activates a rule 
class called STUDENT.DEFICIENCY.RULES in the student model to find an emer¬ 
gency condition which the student is deficient in. If one exists, the tutor model tells 
the domain knowledge model to present the instruction about the emergency condition 
to the student. After the instruction is completed, the TEACH.F4 method tells the 
student model to upgrade the student’s knowledge state to proficient. The 
TEACH.F4 method repeats this procedure until no deficient emergency conditions ex¬ 
ist in the student model. 

The second procedure is then implemented. The TEACH.F4 method activates 
another rule class called PRESENT.EMERGENCY .RULES in the student model to 
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find an emergency condition which the student is proficient in. Next, the method acti¬ 
vates an object in the domain knowledge model corresponding to the emergency con¬ 
dition obtained from the student model to initialize the aircraft model to a state that 
causes the emergency condition. The TEACH.F4 method then invokes the expert 
model for the solution and temporarily stores the information in a slot. The method in¬ 
structs the student to diagnose the current problem and implement a solution to solve 
the problem. This is standard information in the form of text, stored in a slot of the tu¬ 
tor object. Next, the TEACH.F4 method tells the communications model to display 
the aircraft interface so the student can look at the switches and gauges in order to di¬ 
agnose the problem. Upon diagnosing the problem, the student changes switch posi¬ 
tions to solve the problem. The tutor method records all of these changes. When the 
student concludes all changes, the TEACH.F4 method sends the system and student 
solutions to the student model to compare the students solution to the expert model’s 
solution. This procedure is repeated until the student is either deficient in an emer¬ 
gency condition or is proficient in all emergency conditions. 

3. PEPTR Student Model 

The student model is used to maintain a record of the student’s performance. 
It represents the student’s proficiency at diagnosing each emergency condition and 
applying the correct procedure to solve the problem. The student model interacts with 
the domain knowledge model to represent the student’s knowledge state. 

The type of knowledge that the student model currently represents is declara¬ 
tive knowledge. The declarative knowledge is the part of the student model that pro¬ 
vides a reflection of the student’s knowledge state during each tutoring session. We 
used the production rules in the knowledge model to preserve the student’s knowl¬ 
edge state. Since rules are represented as objects in the KEE system, each rule ob¬ 
ject has the same characteristics as the basic object in KEE. Therefore, rule objects 
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can contain slots. We created a slot in each production rule that encapsulates a par¬ 
ticular concept that the student must know. This slot contains a value of deficient or 
proficient, which represents the student’s knowledge of the concept in that rule. Dur¬ 
ing a tutoring session, the student model activates applicable rules to update the val¬ 
ue of this slot to reflect the student’s current proHciency. 

4. PEPTR Communication Model 

This is the interface. Its purpose is threefold: to graphically represent the 
cockpit of an F-4 aircraft to the pilot, to provide windows for student input and sys¬ 
tem feedback, and to furnish a mechanism for the student to invoke the expert system 
while in the reaction mode. 
a. Interface 

The interface contains panels of switches and gauges that depict the cur¬ 
rent switch positions and state of the aircraft The pilot can use the mouse to change 
switch positions and the state of the aircraft (e.g., fuel capacity, fuel rate of flow) to 
either initiate an emergency condition or to apply a solution. Windows appear when 
administrative information is required and during a problem solving session for feed¬ 
back. Figure 11 illustrates a typical screen during a tutoring session. 

The interface is designed for use in two modes of operation: reaction mode 
and instruction mode. During the reaction mode, the student can freely change the 
state of the aircraft to learn what in-flight emergencies are caused by various aircraft 
states and to leam which changes lead to a solution. During this mode, the interface 
provides a button so the student can invoke the expert model to determine the diagno¬ 
sis and correct solution. During the instruction mode, the interface is displayed to the 
student at a certain time during the tutoring process. It is displayed in a predeter¬ 
mined state dependent upon the in-flight emergency selected for the student to solve. 
In this mode, the student makes only the changes required to solve the problem. 
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Figure 11 - PEPTR Interface 

b, KEE Image and Graphics Facilities 

The communication model for PEPTR is essential to the tutoring system. It 
not only acts as the user interface, but graphically represents a cockpit of an aircraft 
and translates user input into a format that the domain knowledge model can use. 
The type of knowledge in the communication model is procedural. We used a proce¬ 
dural representation scheme to represent this knowledge. 

We used the Activelmages facility that the KEE system provides to graph¬ 
ically represent components of a cockpit. Images of these components are attached to 
slots of objects in the aircraft model. We employed seven types of Activelmages: 
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state dials, horizontal push buttons, vertical push buttons, method actuators, horizon¬ 
tal bar graphs, horizontal bar graph actuators, and simple value displays. 

State dials display all possible values of a slot around the top of a dial. The 
needle points to the current value. The user can left-click on the image to change the 
value. We represented switches and circuit breakers in the cockpit with state dials. 

Horizontal and vertical push buttons display all possible values of the at¬ 
tached slot with the current value highlighted. These are actuator images that enable 
the user to change the slot’s value. To select a slot value, the user left-clicks on the 
desired value. All other values are deselected. We used a horizontal push button for 
the user to select a panel in the cockpit. Since a computer screen is not large enough 
to display all of the switches, buttons, and gauges of a cockpit, we designed the inter¬ 
face to display a selected part of the cockpit as determined by the user. Selection of a 
panel displays all of the images that represent switches and gauges corresponding to 
the type of panel (i.e., the electrical panel contains images of circuit breakers). We 
used a vertical push button for the user to select the fuel rate in the aircraft. 

Method actuators provide a way to activate methods. If the user left-clicks 
on a method actuator, the method in the attached slot starts running. While the meth¬ 
od is running, the method actuator image remains inverted. When the method has fin¬ 
ished running, the image returns to its normal state. Text can be inserted in the 
method actuator image that describes or labels the operation it performs. We used 
method actuators for the user to start a method that invokes the expert model to diag¬ 
nose a problem and determine a solution. 

Horizontal bar graphs show the value of a slot via a variable length hori¬ 
zontal bar. The axis is underneath the bar. Horizontal bar graph acmators are simi¬ 
lar, but also allow the user to change the slot value by left-clicking a new length for 
the bar. We used horizontal bar graphs to display the fuel levels of various fuel tanks 
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on the aircraft We used horizontal bar graph actuators for the user to change the fuel 
level in the fuel tanks. 

Simple value displays can be attached to any slot and displays the value as 
a string of text or numbers. It is intended to display a slot with just one value; how¬ 
ever, it can be shaped to display all values of a slot We used simple value displays 
for the user to see the rate of fuel change. 

All images contain functionality derived from knowledge bases within the 
K£E system. This functionality is in the form of methods range from the actions 
which are performed when a mouse button is clicked to the action performed when a 
slot value is changed. These methods represent the procedural knowledge required 
to implement the user’s input. 

E. EXTENSIONS 

A useful extension to the domain knowledge model of PEPTR is a set of emergen¬ 
cy situations for each in-flight emergency. The emergency situations of an aircraft 
would be objects with slots that contain declarative and procedural knowledge to ma¬ 
nipulate the state of the aircraft model. One slot would contain only those aircraft 
components and their state values that cause the certain emergency condition. An¬ 
other slot would contain a method for introducing an in-flight emergency by changing 
the state values of components in the aircraft model. This would initialize the aircraft 
model for a problem solving session on a particular emergency condition. 

One extension necessary for the tutoring process is the addition of an instruction 
model. This part of the domain knowledge model would contain displays of text and 
graphics for teaching the student about the emergency conditions of an aircraft. A 
group of objects corresponding to each of the emergency conditions would have slots 
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that contain the text to present to the student for instruction and a list of applicable 
switches, gauges or other aircraft components to display to the student. 

The following extension to the tutor model would make the tutor model more intel¬ 
ligent and improve the feedback to the student. Currently, the teach method reflects 
somewhat the "discovery" method of learning. It just records the student’s solution 
without any intervention, giving the student full initiative to make any changes de¬ 
sired. A better teaching strategy would be to implement the coaching method during 
the student’s problem solving process. After each smdent operation, the teach meth¬ 
od would invoke the expert model to replan. The method would then invoke a set of 
rules that would check if the operation was correct or incorrect and provide feedback 
accordingly. An incorrect response would result if the student operation caused three 
things. First, the operation caused additional emergency problems. Second, the oper¬ 
ation resulted in no change; the problem is not reduced. Third, the operation prevent¬ 
ed realization of any solution to the problem. The teach method would request from 
the domain knowledge model appropriate feedback depending upon the result of the 
student operation. 

The student model needs additional development to be able to assess a student’s 
knowledge state. We would use production rules and a procedural representation 
scheme to represent the procedural knowledge in the student model. Production rules 
would be written for the following purposes. One set of rules called STU- 
DENT.DEFICIENCY.RULES, would determine the emergency condition which the 
student is deficient at diagnosing or solving. Another set of mles called 
PRESENT.EMERGENCY.RULES, would randomly determine an emergency condi¬ 
tion for instruction if the student was proficient in all emergency conditions. We 
would use a procedural representation scheme to represent the procedural knowledge 
in the student model. The procedure would compare the expert model’s solution to a 
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problem with the student’s solution. The method in the student model would identify 
three things: the changes which the student made that were not in the expert model’s 
solution, the changes in the expert model’s solution which the student failed to imple¬ 
ment, and the correct changes that the student made. For each change that the stu¬ 
dent made incorrectly, failed to make, or made correctly, the student model method 
would identify and activate the rule in the expert model which represents that particu¬ 
lar expertise to update the student knowledge state appropriately. 
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vm CONCLUSION 


A. RESEARCH LESSONS 

Most ICAI systems consist of the four general components required for effective 
instruction. Each component captures a different type of knowledge; knowledge about 
the domain, knowledge about teaching, knowledge about the student, and knov. ledge 
about communication. 

In general, we believe there are three forms of knowledge: declarative knowledge, 
procedural knowledge, and meta knowledge. 

AI researchers and others have developed numerous knowledge representation 
schemes over the past 30 years. Most of these schemes fall into five general catego¬ 
ries. Each category of knowledge representation schemes offers both advantages and 
disadvantages to the system designer. 

The most important aspect of this research is the realization that designers of 
ICAI systems need to employ various knowledge representation schemes to 
represent the different forms of knowledge in an ICAI system. This is evident by 
studying knowledge and knowledge representation schemes, and by studying and 
implementing ICAI systems. 

B. MAPTR AND PEPTR 

The ICAI systems we developed are both diverse and similar in many respects. 
The knowledge domains are quite different as well as the interfaces for each applica¬ 
tion. The general components of a typical ICAI system were used as a framework for 
both systems. 
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MAPTR is a frame-based system that generates a lesson plan tailored to the stu¬ 
dent and provides instruction and evaluation through displays of text and graphics. A 
taxonomy of tasks represents the classification of knowledge into chunks and the re¬ 
lationships among the chunks of knowledge. The tutor model exieiiMvely interacts 
with the knowledge and student models to determine the tasks to be taught, the se¬ 
quence of the instruction, and the training mode. 

PEPTR is a reasoning application for diagnosing aircraft emergency conditions and 
determining solutions to remedy problems. A fr-ame-based aircraft model is utilized 
for representing various aircraft components and their defined states. Reasoning 
about the model is accomplished using a production system. An extensive interface 
resembling the cockpit of an aircraft is provided for the pilot to define or change the 
state of the aircraft. Currently, a pilot retains full initiative during the learning pro¬ 
cess. Future extensions to PEPTR include providing an instructional mode whereby 
the system controls the tutoring process. In addition, the student model will be ex¬ 
tended to include features which allows the system to capture and assess a student’s 
knowledge state. The knowledge model will also be extended to initialize the state of 
the aircraft for a specific emergency condition and to provide instruction to the student. 

C. ACCOMPLISHMENTS 

We designed two distinctly different ICAI systems in an environment that sup¬ 
ported multiple, integrated knowledge representation schemes. The most important 
issue in developing both tutoring applications was choosing the appropriate way of 
representing the knowledge in each component of the tutoring systems. To accom¬ 
plish this, we first determined the types of knowledge to be represented in each com¬ 
ponent. We then selected an appropriate representation scheme for each knowledge 
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type compatible with the tools and techniques provided by the KEE software develop¬ 
ment environment. 

Both applications contain all three forms of knowledge. We used four different 
knowledge representation schemes to represent knowledge in the four components of 
each application. The KEE system supported the creation of objects to represent de¬ 
clarative knowledge and procedural knowledge. It also supported the creation of a se¬ 
mantic network to represent relational knowledge. In addition, the KEE system 
supported the creation of production systems to represent procedural knowledge and 
meta knowledge. 

Clearly, an ICAI system designer is faced with the complex task of determining 
the most natural and applicable knowledge representation scheme for the various 
forms of knowledge contained in the different components of an ICAI system. Thus, 
to reduce the complexity of this task, the designer develop ICAI systems in a pro¬ 
gramming environment that supports multiple, integrated knowledge representation 
schemes. With such a programming environment, designers can implement the most 
natural knowledge representation schemes for all of the knowledge in the system. 

D. FUTURE WORK 

Both applications need additional development to make them become suitable 
ICAI systems for assisting trainers in the instruction of their respective domain 
knowledge. The domain knowledge model of both systems could be expanded to in¬ 
clude the complete body of knowledge required for the users to be proficient at their 
respective tasks. Specifically, PEPTR needs two extensions in the domain knowl¬ 
edge model. One, a set of emergency situations could be added to initialize the air¬ 
craft model for a problem solving session. Two, an instruction model should be 
incorporated to teach the student about the emergency conditions of an aircraft. The 






tutor models of both systems provide limited teaching strategies. Additional tutoring 
strategies could be incorporated to serve the needs of the various users of the sys¬ 
tems. The student model in PEPTR needs additional development to be able to as¬ 
sess the smdent’s knowledge state. With these improvements, both ICAI systems 
could become useful tools for teaching map reading and emergency aircraft procedures. 
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APPENDIX A - SOURCE CODE 


All source code for both ICAI systems is located on the Texas Instrument Explor¬ 
er server called "EXP3". The KEE package for running the applications is located on 
Texas Instrument Explorer called "EXPl". After loading the KEE package, use the 
following pathnames to load either application. 

• MAPTR - exp3:studentthesis.maptr,maptrdesk.lisp 

• PEPTR - exp3:studentthesis.peptr,peptrdesk.lisp 

Each application contains several files of source code. Some files contain code 
generated by KEE for different knowledge bases in an application. A knowledge base 
is a feature of KEE’s frame system that allows a designer to group related objects of 
an application. Other files contain user defined Lisp functions which are methods of 
various objects in the knowledge bases. Each application consists of three knowl¬ 
edge bases. The files for the three knowledge bases in MAPTR are named chapar¬ 
ral.u, system, u, and systemtasks.u. Three additional files in MAPTR contain LISP 
functions for objects of each knowledge base: chaparralfn.lisp, systemfn.lisp, and sys- 
temtasksfn.lisp. The files for the three knowledge bases in PEPTR are named f4.u, 
rules.u, and system.u. The file f4.u contains the objects that represent the aircraft 
model. The rules.u file contains the rule objects for the expert model. The Lisp func¬ 
tion files are called f4fn.lisp, rulesfn.lisp, and systemfn.lisp. 
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APPENDIX B • MAPTR SAMPLE TUTORING SESSION 


The following screen images depict various views of the interface to MAPTR dur¬ 
ing a typical tutoring session. Figure 12 illustrates a general screen image with three 
windows. The lower left window is provided for the user to input textual information 
into the program and for the program to display messages to the user. The upper left 
window displays graphical pictures while the upper right window displays text of do¬ 
main knowledge. A menu is provided in the lower right comer for the user to either 
exit the program or continue the instruction. Figures 12, 13, and 14 illustrate typical 
graphics and text which the program displays for instruction. Figure 15 illustrates an 
evaluation of a task. A menu is provided in the lower right comer for the student to 
select a response. 



Figure 12 - MAPTR Window Layout 


77 















































































APPENDIX C - PEPTR SAMPLE TUTORING SESSION 


The following screen images depict various views of the interface to PEPTR dur¬ 
ing a typical tutoring session. Descriptions of the screen images are also provided. 

Figure 16 shows the opening screen of PEPTR. The student clicks in the login 
button with the mouse to begin the program. 



Figure 16 - PEPTR Login Display 
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Figures 17 and 18 show how a student enters administrative data and the menu 
the student uses to select the mode of instruction (tutor or reactive). 



Figure 17 - PEPTR Administrative Display 
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Figure 18 - PEPTR Instruction Mode Display 
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Figure 19 illustrates the general screen display which the student uses to select 
different actions to include displaying aircraft panels, changing the aircraft state, and 
invoking the expert model to diagnose a problem and show the solution. The student 
displays a panel by clicking on the top image labeled "Panels". The student can dis¬ 
play additional screen images for changing the state of the aircraft by clicking on the 
button labeled "SET AIRCRAFT STATE". The button labeled "DIAGNOSE EMER¬ 
GENCIES" invokes the expert model to determine the emergency condition if one ex¬ 
ists. The button labeled "DIAGNOSE AND GENERATE SOLUTION" also 
diagnoses the problem and additionally provides the solution to correct the problem. 
The exit button allows the student to halt the program. 
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Figure 19 - PEPTR General Display 























Figure 20 shows the message which the program displays if the student clicks on 
the "DIAGNOSE EMERGENCIES" button before changing the aircraft state. The 
aircraft model is initialized to a normal state. 



Figure 20 - PEPTR Diagnose Emergencies Display 
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Figure 21 shows the various switches and fuel gauges that are contained in the fu¬ 
el system panel. They are displayed when the student clicks on the image labeled 
"Panels". Figure 22 shows the circuit breakers contained in the electrical system 
panel. Note, two of the circuit breakers are "out". Instructions arc provided in the 
KEE typescript window. 
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Figure 21 - PEPTR Fuel System Panel Display 
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Figure 22 - PEPTR Electrical System Panel Display 















Figures 23 and 24 show the images that are displayed when the student selects 
the "SET AIRCRAFT STATE" button. The student can click on the fuel gauge actua¬ 
tors in figure 24 to set the quantity of fuel desired in each fuel tank. Note, the fuel in 
the fuselage tank has been reduced to 6000 lbs. The button labeled 
"ADDrriONAL.STATES" displays the images in figure 24. The student can select 
the desired rate of fuel flow by clicking on one of the values in the "change rate" imag- 



Figure 23 - PEPTR Set Aircraft State Display 
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Figure 25 shows the message which is displayed after the student has clicked on 
the "DIAGNOSE EMERGENCIES" button to invoke the expert model. The two cir¬ 
cuit breakers that were "out" in figure 22 combined with the reduction of fuel shown in 
figure 23 produced the emergency condition shown in the message. Figure 26 shows 
the solution which the program displays if the "DIAGNOSE AND GENERATE SO¬ 
LUTION" button is actuated. 



Figure 25 - PEPTR Diagnose Emergencies Display 
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Figure 27 shows the state of the circuit breakers after the student initiated the 
corresponding remedial actions concerning the diagnosed problem. Figure 28 shows 
the message which is displayed after the student has clicked on the "DIAGNOSE 
EMERGENCIES" button again to invoke the expert model. Since the student initiat¬ 
ed only a partial solution, the expert model diagnosed the same problem and dis¬ 
played the remaining remedial actions to correct the problem. Figure 29 shows the 
state of the switches on the fuel system panel after the student initiated the remain¬ 
ing remedial actions which alleviated the emergency condition. 



Figure 27 • PEPTR Changing Electrical System State Display 
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Figure 28 - PEPTR Partial Solution Display 
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Figure 29 - PEPTR Changing Fuel System State Display 
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